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

Jeremy Stanley fungi at yuggoth.org
Thu Sep 9 13:09:03 UTC 2021

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210909/78a5bc4e/attachment.sig>

More information about the openstack-discuss mailing list