Missing eclipse-qvtd
Please create the wiki repo for QVTd. (Nothing listed on PMI page.)
Activity
Wiki repos on both Gitlab and Github are generally co-located with code repositories, so they don't tend to be 'independent'. That doesn't mean they can't be, only that it's not the default workflow.
If qvtd has a code repository at say: gitlab.eclipse.org/eclipse/qvtd/org.eclipse.qvtd , you can create the associated wiki repository by browsing to the repo, and clicking 'Plan -> wiki' in the left hand nav bar. Then just click on 'create your first page' button, add some text(hello world?) and click save at the bottom of the page. That will init the wiki repository(with a name of gitlab.eclipse.org/eclipse/qvtd/org.eclipse.qvtd.wiki) and you can then clone it and interact with it like a normal git repo.
If the project would like the wiki content to be co-located with the website content repos, that's up to them, but I think it would be better associated with the project code itself.
Part of the issue here is that both qvtd(and qvto(#4082 (closed))) appear to still be running on our Gerrit instance so they don't have an actual 'home' on either Gitlab or Github as the code repos haven't been moved yet.
That is because as sub-projects of MMT they look like MMT repos(from a filesystem perspective) and since MMT hasn't been moved yet either, these projects went unnoticed. I've broken them out in our tracking doc so we can add them to the list of projects to be moved.PLs or interested committers(with a +1 from the PL) are free to request(via a helpdesk ticket) their project be moved to either Gitlab or Github before it becomes one of the projects we pick to move in any given quarter. We'll do our best to accommodate the projects desired timing.
mentioned in issue #4082 (closed)
As so often I am confused. I expect my four projects to be similar. There is an https://github.com/eclipse-ocl/ocl-website so I just ask for the same for QVTd (and QVTo and MoDisco).
Code is highly synchronized with SimRel and only updated by committers.
Wiki is ad hoc and may be edited by non-committers.
I cannot see why Wiki and code could be in the same repo.
Documentation is more synchronized and more likely to be by committers so why is the website separate?
There is an https://github.com/eclipse-ocl/ocl-website so I just ask for the same for QVTd (and QVTo and MoDisco).
The websites for QVTo, QVTd were simply links to projects.eclipse.org, and so they were replaced with static redirects. If you're planning on creating web content for these projects, I'm happy to create the appropriate organizations and repos for you.
For the Modisco website, it was moved into the Eclipse organization on Github, rather than it's own organization because of how early in this transition it was moved(OCL was moved later), so we should correct that when the code repository moves, or we can do it now if you like.
In order for everyone to familiarize themselves with how Gitlab/Github function, we elected to move the project websites before the code as that was deemed to be lower risk. Since then our workflow has been to move 15-20 random projects per quarter to Gitlab/Github, with the goal of having all projects moved before the shutdown of our Gerrit instance.
If you don't want to wait until we get to your project(s), just file an issue here requesting the move and we'll do our best to work with your timing. We can repurpose this issue for that work if you like.
Wiki is ad hoc and may be edited by non-committers.
While true, in practice the wiki pages for any project are maintained(or not) by the relevant project.
I cannot see why Wiki and code could be in the same repo.
I think my use of 'co-located' may be at issue here. I didn't mean 'co-located' as 'the wiki is located within the project code repository', but as 'the wiki is located next to the project code repository'.
Part of the confusion is that from the Gitlab/Github web-uis it sure looks like the wiki is within the associated code repo, but in reality it's a separate repo(That any committer on the project can create/init via the web UI).
Developers, projects and users seem to prefer this appearance of tighter integration between their code and documentation.
Documentation is more synchronized and more likely to be by >committers so why is the website separate?
Projects are free to make their documentation available via their websites, integrated within the code repositories, as a separate repository, or a 'co-located' wiki as they like.
Traditionally project websites have been a bit of a mix of marketing and documentation, but the trend seems to be moving these sites towards more of a marketing/community building approach with the documentation elsewhere.
@ewillink Just to make sure that we understand each other - I suggest the following steps to organize the repositories
- I create
eclipse-qvtd,eclipse-qvtoandeclipse-modiscoorganizations on Github. I'll move the content ofeclipse/modisco*to the last one - I move the qvtd and qvto repositories to these new organizations
- I'll enable the in-built wiki pages on those repositories
Does it work for you?
- I create
@ewillink we discussed this in the team and we concluded that we are not able to provide globally writable eclipse-wiki organization.
In order for this to be adopted across the projects, there would have to be change in a way they handle their documentation. We do not see any indication of a widespread demand among the projects for this feature. We also struggle with issue of spam on Gitlab and it already is an uphill battle. Creating an organization where anyone with ECA could create a repository would make it even harder. Even if we deployed such a feature on Gitlab, which in order to make it automatic would have to include quite a lot of custom scripting, we wouldn't be able to replicate it on Github, where majority of projects live.
What I am offering is a simple in-built Gitlab wiki repository, editable by project committers. I suppose that (moderated) edits by external contributors should be possible via MRs.
mentioned in issue #3816 (closed)
assigned to @jmazanek4ep
-
Sorry this is not acceptable.
The EF should be making things steadily better for users and projects. THe EF now seems to be only interested in helping the EF.
An Open Source community must foster its users. Losing the ease of wiki editing versus the pain of needing PRs and a clone is pretty dubious. Limiting edits to project committers is unacceptable. Most project committers are too busy to respond in a timely fashion, if at all, to external PRs.
I have made quite a few contributions to the Tycho FAQ. All ECAs must be able to do likewise.
Sorry but this is why I am standing down and cannot accept this wiki destruction.
Ed, the EF does not exist to satisfy it's own needs; the EF is here to serve and help its communities. We are making changes to the infrastructure to improve that service offering. Although it's possible that you do not agree with what is being done, the purpose is to help the community.
I'm sorry you find this unacceptable. I will agree that the GitLab wiki experience is not as good as the MediaWiki one (not even close) but the monolithic Wiki has become a vast wasteland of outdated and abandoned content which does not make any of our projects look good.
GitLab (and GitHub) do excel at just about everything else, including markdown and greater repository/issues/epic management and planning, as well as integrated CI. Although the wiki experience is lesser, the overall experience is a large improvement.
Again, you are free to disagree, and that is unfortunate. If you still find this unacceptable, I suggest you consult with your project's PMC, or discuss with your elected committer representatives (https://www.eclipse.org/org/foundation/directors.php)
-
excel at just about everything else
On (#4380 (comment 1889940)) you wrote:
Apart from that, the search functionality in GitLab issues is completely useless and can not be trusted.
Why are you so determined to trash the user/committer experience?
Every morning, when the E(vil)Foundation IT team convenes in a secret, hidden lair to plot the best plan to make committer's lives more miserable - while pretending to upgrade everything - we ask ourselves:
- Was the search functionality better in Bugzilla than in GitLab? Yes
- Was public access to the old wiki easier? Yes
- Is GitLab perfect? No
- Can we continue to run unsupported and unmaintained software? No
- Is GitLab the best compromise? AFAWK, yes
- Will we consider (feasible) alternatives in the future? Yes
With GitLab, we have at least a chance that the search functionality improves at some point (heck, someone could even try to provide a patch for it).
Nothing is perfect, especially not software. I'm sure you have noticed that before. So all we can do, is to find the best compromise at the time and stop delving into unsubstantiated accusations of malice.
Edited by Frederic Gurr
added team:infra label
