[oslo][release] Changing back release model of tooz ?
Hello, As you may know, tooz was moved to the independent release model[1] after wallaby release because of its stable code base at that time. However, we introduced several features/improvements in tooz during a few cycles and I'm wondering if we can revisit its status now. One actual problem I'm seeing now is that, we recently got a bug report[2] about the redis sentinel support which we added during 2024.1 cycle but we can't backport the required bug fix to 2024.1 because of no stable branch. Given the situation, I'm wondering if it makes sense (and is possible) to move tooz back to the cycle-with-intermediary model, and create 2024.1 branch from 6.1.0 (the last release during 2024.1 cycle) now, so that we can maintain 2024.1 releases with future bug fixes brackported. [1] https://review.opendev.org/c/openstack/releases/+/788230 [2] https://bugs.launchpad.net/python-tooz/+bug/2063857 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
Um, I'm slightly confused. Isn't point of independent release to eliminate need of such backports? As you are should be just able to use newest/latest release for caracal as well? So maybe it's matter of just bumping tooz version in upper-constraints for caracal rather than changing the release model? As according to the bug report and patch for it - I don't see why we would want to change release model, rather then build/package new version of tooz for caracal. On Wed, May 8, 2024, 08:54 Takashi Kajinami <kajinamit@oss.nttdata.com> wrote:
Hello,
As you may know, tooz was moved to the independent release model[1] after wallaby release because of its stable code base at that time.
However, we introduced several features/improvements in tooz during a few cycles and I'm wondering if we can revisit its status now. One actual problem I'm seeing now is that, we recently got a bug report[2] about the redis sentinel support which we added during 2024.1 cycle but we can't backport the required bug fix to 2024.1 because of no stable branch.
Given the situation, I'm wondering if it makes sense (and is possible) to move tooz back to the cycle-with-intermediary model, and create 2024.1 branch from 6.1.0 (the last release during 2024.1 cycle) now, so that we can maintain 2024.1 releases with future bug fixes brackported.
[1] https://review.opendev.org/c/openstack/releases/+/788230 [2] https://bugs.launchpad.net/python-tooz/+bug/2063857
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit
Isn't point of independent release to eliminate need of such backports? As you are should be just able to use newest/latest release for caracal as well? I believe no. IIUC the point was to eliminate need of stable branch maintenance which is redundant for stable components.
In general independent release model makes it difficult to pull bug fixes to stable branches, because once any breaking change or new feature is introduced in master then we no longer able to bump versions in stable branch u-c. For example we will remove python 3.8 support during this cycle, so once we get a new release with python 3.8 support removal then we may no longer able to bump stable constraints. Some of the oslo's deliverables such as oslo.messaging was switched back to cycle model after we faced such situations. Creating a bug fix release may work or this specific case, but my concern is that we may face problems in case we get some more bugs reported in the future, and we have more such risks nowadays after a few active development cycles. On 5/8/24 20:36, Dmitriy Rabotyagov wrote:
Um, I'm slightly confused.
Isn't point of independent release to eliminate need of such backports? As you are should be just able to use newest/latest release for caracal as well?
So maybe it's matter of just bumping tooz version in upper-constraints for caracal rather than changing the release model?
As according to the bug report and patch for it - I don't see why we would want to change release model, rather then build/package new version of tooz for caracal.
On Wed, May 8, 2024, 08:54 Takashi Kajinami <kajinamit@oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> wrote:
Hello,
As you may know, tooz was moved to the independent release model[1] after wallaby release because of its stable code base at that time.
However, we introduced several features/improvements in tooz during a few cycles and I'm wondering if we can revisit its status now. One actual problem I'm seeing now is that, we recently got a bug report[2] about the redis sentinel support which we added during 2024.1 cycle but we can't backport the required bug fix to 2024.1 because of no stable branch.
Given the situation, I'm wondering if it makes sense (and is possible) to move tooz back to the cycle-with-intermediary model, and create 2024.1 branch from 6.1.0 (the last release during 2024.1 cycle) now, so that we can maintain 2024.1 releases with future bug fixes brackported.
[1] https://review.opendev.org/c/openstack/releases/+/788230 <https://review.opendev.org/c/openstack/releases/+/788230> [2] https://bugs.launchpad.net/python-tooz/+bug/2063857 <https://bugs.launchpad.net/python-tooz/+bug/2063857>
-- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit <https://github.com/kajinamit> launchpad: https://launchpad.net/~kajinamit <https://launchpad.net/~kajinamit>
On 2024-05-08 21:23:25 +0900 (+0900), Takashi Kajinami wrote: [...]
In general independent release model makes it difficult to pull bug fixes to stable branches, because once any breaking change or new feature is introduced in master then we no longer able to bump versions in stable branch u-c. For example we will remove python 3.8 support during this cycle, so once we get a new release with python 3.8 support removal then we may no longer able to bump stable constraints. [...]
I think the original intent was to keep such libraries compatible with all maintained stable branches. If you run some stable branch jobs from the oldest currently maintained branch on all proposed changes, that can act as insurance against accidentally breaking things. This is the approach which, e.g., PBR takes, though in that case we try to keep it compatible with unmaintained branches too since it's basically impossible to pin. -- Jeremy Stanley
On 5/8/24 22:26, Jeremy Stanley wrote:
On 2024-05-08 21:23:25 +0900 (+0900), Takashi Kajinami wrote: [...]
In general independent release model makes it difficult to pull bug fixes to stable branches, because once any breaking change or new feature is introduced in master then we no longer able to bump versions in stable branch u-c. For example we will remove python 3.8 support during this cycle, so once we get a new release with python 3.8 support removal then we may no longer able to bump stable constraints. [...]
I think the original intent was to keep such libraries compatible with all maintained stable branches. If you run some stable branch jobs from the oldest currently maintained branch on all proposed changes, that can act as insurance against accidentally breaking things. This is the approach which, e.g., PBR takes, though in that case we try to keep it compatible with unmaintained branches too since it's basically impossible to pin.
I'm not too sure if that was the original intention at least for oslo, given the fact that all independent deliverables have been using the latest python job template, and drops support for old python versions once removed from master. We can technically try this approach, but longer life cycle of unmaintained branches is making the overall maintenance quite difficult. I'd rather prefer restoring stable branch concept here, which we've done for the other oslo repos.
The original intent behind the independent model transition for tooz was reduce the number of stable branches to maintain. At this time, tooz felt like a stable deliverable. If it makes our life more simple, then, I'm ok to move back tooz to the coordinated series. We already moved back several oslo deliverables. I'd encourage us to uniformize similar cases. Le mer. 8 mai 2024 à 16:38, Takashi Kajinami <kajinamit@oss.nttdata.com> a écrit :
On 5/8/24 22:26, Jeremy Stanley wrote:
On 2024-05-08 21:23:25 +0900 (+0900), Takashi Kajinami wrote: [...]
In general independent release model makes it difficult to pull bug fixes to stable branches, because once any breaking change or new feature is introduced in master then we no longer able to bump versions in stable branch u-c. For example we will remove python 3.8 support during this cycle, so once we get a new release with python 3.8 support removal then we may no longer able to bump stable constraints. [...]
I think the original intent was to keep such libraries compatible with all maintained stable branches. If you run some stable branch jobs from the oldest currently maintained branch on all proposed changes, that can act as insurance against accidentally breaking things. This is the approach which, e.g., PBR takes, though in that case we try to keep it compatible with unmaintained branches too since it's basically impossible to pin.
I'm not too sure if that was the original intention at least for oslo, given the fact that all independent deliverables have been using the latest python job template, and drops support for old python versions once removed from master.
We can technically try this approach, but longer life cycle of unmaintained branches is making the overall maintenance quite difficult. I'd rather prefer restoring stable branch concept here, which we've done for the other oslo repos.
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
participants (4)
-
Dmitriy Rabotyagov
-
Herve Beraud
-
Jeremy Stanley
-
Takashi Kajinami