[all] Dangerous trend toward too many release-independent components
zigo at debian.org
Thu Sep 9 15:12:01 UTC 2021
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-date": "Thu Jul 15 10:19:24 2021 +0000",
"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
> 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?
Thomas Goirand (zigo)
More information about the openstack-discuss