On 2021-09-08 11:31:31 +0200 (+0200), Herve Beraud wrote: [...]
An API seems quite a good idea
I'm ok to give help on this point with my upstream cap and my Red Hat cap.
As release manager I added your proposition to our "things to changes" on our release process and tools. I think that it should be discussed first to see how to implement it and how to host it. I think that the technical details would be a transversal decision between the infra team and the release team and the volunteers on this topic. [...]
Note that an API in this sense can just be a consumable data structure. The amount of release metadata associated with a coordinated release of OpenStack isn't exactly tiny, but it's not so large it couldn't just be serialized into some sort of structured data file which tools can consume. The upper-constraints.txt redirector on the releases site provides one such example, though its not rich enough in detail for the described use case as far as I can tell. The series deliverable files in the releases repo are another such example, but they probably have a little too much detail and at the same time, as pointed out, don't associate independent deliverable releases with release cycles (the crux of the issue which is raised here).
I think a good starting point could be to design some specs or propose some related goals, so, Thomas, maybe you could start by creating something like that with your expectations. It will allow us to start this topic, share our different feedback and our expectations on it (our different viewpoints, at least from the release team, infra team, and downstream/distros teams). [...]
Which then begs the question, where should such a design specification document be proposed/reviewed? The release team doesn't have a specs repo, but also it might be sufficient to attempt to use this mailing list to hammer out a clearer explanation of the data people are looking for and the methods they would be comfortable employing to obtain it. -- Jeremy Stanley