[oslo] Moving back oslo deliverables to the cycle with intermediary release model
Hey Osloers,
Months ago we moved a couple of oslo deliverables to the independent release model [1][2], however it led us to issues with backports [3].
Backports are not an option for those deliverables.
During the previous release management team' PTG we discussed this topic and we decided [4] to move back the oslo deliverables to the cycle-with-intermediary model.
You can follow the transition to the CWI model through this patch https://review.opendev.org/c/openstack/releases/+/864095
Do not hesitate to react directly to the patch.
Thanks for your time.
[1] https://lists.openstack.org/pipermail/openstack-discuss/2020-November/018527... [2] https://opendev.org/openstack/releases/commit/5ecb80c82ed3ab0144c8e5860ee62d... [3] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/03061... [4] https://etherpad.opendev.org/p/oct2022-ptg-rel-mgt
On 11/9/22 09:59, Herve Beraud wrote:
Hey Osloers,
Months ago we moved a couple of oslo deliverables to the independent release model [1][2], however it led us to issues with backports [3].
Backports are not an option for those deliverables.
During the previous release management team' PTG we discussed this topic and we decided [4] to move back the oslo deliverables to the cycle-with-intermediary model.
You can follow the transition to the CWI model through this patch https://review.opendev.org/c/openstack/releases/+/864095 https://review.opendev.org/c/openstack/releases/+/864095
Do not hesitate to react directly to the patch.
Thanks for your time.
Hi,
FYI, I very much welcome this move. I'd prefer if most OpenStack deliverable was going back to this kind of release management.
As a downstream package maintainer, it was very hard to know what I should be doing in terms of backporting too. With these going back to "normal", it's a lot more clear.
Thanks a lot, Cheers,
Thomas Goirand (zigo)
On Wed, 2022-11-09 at 09:59 +0100, Herve Beraud wrote:
Hey Osloers,
Months ago we moved a couple of oslo deliverables to the independent release model [1][2], however it led us to issues with backports [3].
Backports are not an option for those deliverables.
that is only true because we do not create brances for each y stream in the x.y.z naming
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.
really what you woudl want to do is select a subset of LTS release that you create the branch for and backport too that effectivly is what cycle-with-intermediary will give you. you will have one "lts" release per upstrema cycle as cycle-with-intermediary requires at least one release a cycle but like indepenent allows arbviarty adtional release at any time in the cycle outside the freeze periods.
During the previous release management team' PTG we discussed this topic and we decided [4] to move back the oslo deliverables to the cycle-with-intermediary model.
You can follow the transition to the CWI model through this patch https://review.opendev.org/c/openstack/releases/+/864095
Do not hesitate to react directly to the patch.
Thanks for your time.
[1] https://lists.openstack.org/pipermail/openstack-discuss/2020-November/018527... [2] https://opendev.org/openstack/releases/commit/5ecb80c82ed3ab0144c8e5860ee62d... [3] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/03061... [4] https://etherpad.opendev.org/p/oct2022-ptg-rel-mgt
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.
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
On 2022-11-09 13:42:55 +0000 (+0000), Sean Mooney wrote: [...]
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.
[...]
Another difference implied there is that we will increase the versions of cycle-with-intermediary dependencies in the otherwise frozen upper-constraints.txt lists in stable branches of the openstack/requirements project. A point release from a "stable" branch of an independent release project isn't afforded this exception, and for good reason (because it's not required to follow the more stringent releasing and branching processes we expect of cycle-based deliverables).
participants (4)
-
Herve Beraud
-
Jeremy Stanley
-
Sean Mooney
-
Thomas Goirand