[all] Dangerous trend toward too many release-independent components

Thomas Goirand 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-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)



More information about the openstack-discuss mailing list