Rethink how we represent simultaneous release participation
For every release, we (I) compile a participating projects page (e.g. 2022-12) and initiate a dance over cross-project-dev-issues to sort out specific versions included in releases and whatnot. These pages are generated using records that map a specific simultaneous release instance to specific release records for individual Eclipse open source projects.
The association between the simultaneous release and project release record is used to automatically generate participation statements in the PMI.
e.g., for a release record you'll see something like this:
"This release is part of ..." is generated based on the association. A similar statement is generated on the project's PMI page as well.
We also use this information to generate stats that we include on the various simultaneous release marketing pages. For the purposes of running states, we only need the ID of each of the participating projects (that is, we don't actually use the release version information). From that ID, we can identify the repositories owned by the various participating projects and run queries to collect stats (contributors, committers, lines of code, ...) based on that.
There's a couple of corner cases where we do actually leverage the release records to get information about participating subprojects. For example, the Eclipse project participates in the Simultaneous Release as a single project, but actually includes content from some -- but not all -- subprojects (the list of subprojects is included in the release record). I believe that it's only the Eclipse and and Eclipse Web Tools projects that do this.
I'd like to rethink how we do this. The disconnect between the work that committers do and the tracking that we do for the release results in a lot of very manual work to keep the information in sync, which introduces potential for errors. That, and it's not clear that the manual work actually adds value.
As an aside: It may be time to just move on from release records and just let projects do releases however they feel is best for their community. If we need release information, we can query it from GitLab and GitHub. Whatever we decide here could be a step towards making that happen.
I've made some passes at making reasonable guesses at participating projects from the aggrcon files, but there's enough variety in them that it would require a lot of hinting. We can correctly guess, for example, that the fact that cdt.aggrcon exists in the repository and is enabled means that tools.cdt is participating in the release. But there are some aggrcon files that represent multiple projects and cases where single projects have multiple aggrcon files. I tinkered a bit with making good guesses based on the repository records in the document, but even that requires some educated guesses.
And, frankly, I'd rather not guess. Further, I'd like to see what we can do to completely automate all the things that we do with this data, and requirements manual intervention would impact that.
I'm thinking that it would be useful to include project IDs directly in the aggrcon files. The primary idea being that having the information all in one place improves our chances that it will be maintained and therefore correct. If we decide that version information is no longer interesting, it may be the case that we can just update these files with the information once and then never have to think about it again. If version information is considered interesting, then we'll need to capture that here as well; and that that may require periodic "thinking about".
We'd need to be able to list multiple project IDs. For example, ep.aggrcon would need to include eclipse.platform, eclipse.equinox, eclipse.jdt, ...
Questions...
Is the release version information useful to anybody?
Is including the "This release is part of..." statement on release and project records in the PMI valuable?
Based on responses to the above, here's what I'm thinking:
- we make it a requirement to put project IDs into the
aggrconfiles - we remove the "This release is part of ..." functionality from the PMI
- we snapshot data extracted from the
aggrconfiles and use it to generate the simultaneous release participating project pages - we remove version information from the simultaneous release participating projects pages
This is just a brain dump. I'm open to other ideas.