On 9/9/21 3:09 PM, Jeremy Stanley wrote:
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.
Yes, that's more or less what I was thinking. Something like: curl -X GET http://releases.openstack.org/api/release/xena { "release-name": "xena", "components": { "oslo.config": { "version": "8.7.1", "release-date": "Thu Jul 15 10:19:24 2021 +0000", }, "oslo.db": { "version": "11.0.0", "release-date": "Mon Aug 23 10:23:24 2021 +0000", }, ... } } That'd be a way more reliable to parse than the HTML page like we do right now...
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).
Where's the "series deliverable files" that you're talking about?
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.
Same over here: where should we propose such specs? Cheers, Thomas Goirand (zigo)