[oslo] Moving back oslo deliverables to the cycle with intermediary release model
Sean Mooney
smooney at redhat.com
Wed Nov 9 13:42:55 UTC 2022
On Wed, 2022-11-09 at 13:21 +0000, Jeremy Stanley wrote:
> On 2022-11-09 12:00:29 +0000 (+0000), Sean Mooney wrote:
> [...]
> > if we did that then you could delvier bugfix z relases with select
> > backports.
> >
> > moving back to release with intermediary is proably fine but ohter
> > then process restrictions i dont think there is anythign that
> > woudl prevent an independed released compentent form doing
> > backports if they really wanted too.
> [...]
>
> It's not a problem of logistics, but rather policy. Independently
> released projects are intended to be treated like other external
> dependencies which are completely disconnected from our coordinated
> cycle. Yes they could still add "stable" branches and backport fixes
> to those and tag point releases from them, but as with external
> dependencies we intentionally keep their versions frozen in our
> central constraints list, so those backports don't actually get the
> same degree of integration testing as cycle-with-intermediary
> projects do. And if you keep unwinding the policy restrictions in
> order to make independent projects behave more like cycle-based
> projects, addressing the issues each of those policies is meant to
> mitigate, you eventually end up at something very much like
> cycle-with-intermediary anyway.
yep i was not objecting to the mvoe but to me the reall delta between cycle-with-intermediary
and independent is just that 1 there will be at least one release per upstream cycle and 2 there will
be a stable barnch created from the final release of the cycle that may recive backport in the future if
as a team we decied the backport is warented.
cycle-with-intermediary shoudl be the default choice i think for most projects/repos
More information about the openstack-discuss
mailing list