Community
Participate
Working Groups
Unless there is a good reason to keep both sections separate, they should be merged into a single source repo section. It should not matter if a repo is hosted on git.eclipse.org or github.com/eclipse. Sync tooling might need to be adapted accordingly.
As a datapoint: in bug 543455 the duplication of repos caused confusion and required extra work.
Yet another bug that was caused by this issue: bug 544376. Raising priority.
Any love for this one?
Background: When the source repositories field was originally envisioned, I decided that committers could/should be able to manipulate it. The field supports wildcards, so it's possible to just put "/gitroot/dash/*" to have the page list all (originally Git, now Gerrit) repositories that match (a background script harvests the repository list from Gerrit into a database in the "dashboard" database that's used for matching); which is what we do for most projects. But committers can also list more specific repositories and control order. The code actually supports a combination of specific repositories and wildcards, sorted, and without duplicates. One of the benefits of the wildcards (and the primary reason why they were added) was to ensure that we had an easy means of making sure the information was as up-to-date as possible. The webmaster could create a repository in Git (now in Gerrit) and it would just automatically appear without any further intervention. Project alignment (i.e., committer access) is all managed via Gerrit. The source repositories field basically reflects what we have in Gerrit. The GitHub and GitLab repository fields are different. They are the source of truth regarding who should have committer access on each of those services. That is, the webmaster doesn't have to make any changes to the source repositories field, but *must* set values for GitHub and GitLab repositories. Giving the committers the ability to manipulate the source repositories field introduces some challenges. They can get it wrong, for one and we can have situations where the same repository is claimed by two projects. This has no impact on committer access, but confuses commit charts and other stats. We've had cases where a container project would include the repositories for subprojects in their list, for example (we do this roll up automatically now). I am thinking that we can simplify by removing committer access to the field. That would mean, though, that webmaster would take on responsibility for ensuring that field is set to a correct value. Note that there is a Drupal idiosyncrasy with this field. We display the "source repositories" field. While displaying this field, there's a bit of Drupal magic that also grabs the GitHub and GitLab repositories and displays them too. When the "source repositories" field is blank, the PMI does not display any repositories (regardless of whether or not there are values in the GitHub and GitLab repository list). To work around this, I set the "source repositories" field to "/gitroot/bogus/*" which matches to an empty list that is then augmented with the GitHub and GitLab repositories. This is, to say the least, weird. I welcome a better solution. The extra work of maintaining the mapping notwithstanding, I would be in favour of dismantling the wildcard feature (there are some weird corners where this is problematic).
This issue has been migrated to https://gitlab.eclipse.org/eclipsefdn/it/websites/projects.eclipse.org/-/issues/63.
