[tc] How to indicate that a project will transition straight to EOL
o/ I've noticed that a variety of SDK-related projects have had 'Update .gitreview for unmaintained/wallaby' patches proposed against them, e.g [1]. I'm not sure this makes much sense. Both SDK and OSC are designed to work against any version of OpenStack so there's hardly a reason to keep stable branches around, let alone the unmaintained branches. I took a look through the Project Team Guide docs [2] but while I can find info on opting-in to keep older unmaintained branches around, I can't find any info on opting-out of their creation altogether. That brings me to my question: does such a thing exist, and if not, can it? How can we ensure we go straight from stable to EOL for these projects? As a separate point, we may wish to explore removing stable branches entirely for these projects. Open to input on whether this is even possible, or if their removal would have serious issues for folks. Cheers, Stephen [1] https://review.opendev.org/c/openstack/openstacksdk/+/911660 [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintai...
---- On Mon, 22 Apr 2024 09:45:42 -0700 Stephen Finucane wrote ---
o/
I've noticed that a variety of SDK-related projects have had 'Update .gitreview for unmaintained/wallaby' patches proposed against them, e.g [1]. I'm not sure this makes much sense. Both SDK and OSC are designed to work against any version of OpenStack so there's hardly a reason to keep stable branches around, let alone the unmaintained branches. I took a look through the Project Team Guide docs [2] but while I can find info on opting-in to keep older unmaintained branches around, I can't find any info on opting-out of their creation altogether.
I think this can be done by -1 from unmaintained liaison or PTL when the unmaintained branch cut is proposed. All these pre-SLURP model branches are going to be unmaintained but once we Antelope comes to the stage of moving from a supported branch then it will be easy as only the SLURP branches are supposed to be moved to unmaintained which is default but can be opt-out by -1 the release change. I can propose this to document if it help.
That brings me to my question: does such a thing exist, and if not, can it? How can we ensure we go straight from stable to EOL for these projects?
As a separate point, we may wish to explore removing stable branches entirely for these projects. Open to input on whether this is even possible, or if their removal would have serious issues for folks.
Agree with you, I do not find any reason why we need a stable branch for something whose current/master version is supposed to work against all supported OpenStack releases. I am in favour of removing the stable branch and that way we will be able to keep backward compatibility in a better and easier way. We can release a tag at every release or when the release moves to unmaintained so that that tag can be used for unmaintained branches testing if the current/master version does not work. Same model, we are doing for Tempest. -gmann
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/openstacksdk/+/911660 [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintai...
On Mon, 2024-04-22 at 10:08 -0700, Ghanshyam Mann wrote:
---- On Mon, 22 Apr 2024 09:45:42 -0700 Stephen Finucane wrote ---
o/
I've noticed that a variety of SDK-related projects have had 'Update .gitreview for unmaintained/wallaby' patches proposed against them, e.g [1]. I'm not sure this makes much sense. Both SDK and OSC are designed to work against any version of OpenStack so there's hardly a reason to keep stable branches around, let alone the unmaintained branches. I took a look through the Project Team Guide docs [2] but while I can find info on opting-in to keep older unmaintained branches around, I can't find any info on opting-out of their creation altogether.
I think this can be done by -1 from unmaintained liaison or PTL when the unmaintained branch cut is proposed. All these pre-SLURP model branches are going to be unmaintained but once we Antelope comes to the stage of moving from a supported branch then it will be easy as only the SLURP branches are supposed to be moved to unmaintained which is default but can be opt-out by -1 the release change. I can propose this to document if it help.
Yes, it would be helpful to get this noted in the document. As I noted, I did read it but this wasn't obvious even after doing so.
That brings me to my question: does such a thing exist, and if not, can it? How can we ensure we go straight from stable to EOL for these projects?
As a separate point, we may wish to explore removing stable branches entirely for these projects. Open to input on whether this is even possible, or if their removal would have serious issues for folks.
Agree with you, I do not find any reason why we need a stable branch for something whose current/master version is supposed to work against all supported OpenStack releases. I am in favour of removing the stable branch and that way we will be able to keep backward compatibility in a better and easier way. We can release a tag at every release or when the release moves to unmaintained so that that tag can be used for unmaintained branches testing if the current/master version does not work. Same model, we are doing for Tempest.
Yeah, the only reason I can think of is the same thing Dmitry called out elsewhere, namely that we may want to backport fixes if we make large breaking changes. However, that happens exceedingly rarely [*] nowadays and I would assume the independent model would let us create e.g. `stable/3.x` branches if needed? Cheers, Stephen [*] openstacksdk 1.0 was a breaking change, but 2.0 and 3.0 only happened because of a removal - which was really more of a replacement - of a small feature [1] and removal of Python 3.6 and 3.7 support [2]). I'm actually not sure what warranted the last major version (to 6.x) bump of OSC). [1] https://review.opendev.org/c/openstack/releases/+/898111 [2] https://review.opendev.org/c/openstack/releases/+/909399
-gmann
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/openstacksdk/+/911660 [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintai...
Hi, A comment on the separate point. On 4/22/24 18:45, Stephen Finucane wrote:
o/
I've noticed that a variety of SDK-related projects have had 'Update .gitreview for unmaintained/wallaby' patches proposed against them, e.g [1]. I'm not sure this makes much sense. Both SDK and OSC are designed to work against any version of OpenStack so there's hardly a reason to keep stable branches around, let alone the unmaintained branches. I took a look through the Project Team Guide docs [2] but while I can find info on opting-in to keep older unmaintained branches around, I can't find any info on opting-out of their creation altogether.
That brings me to my question: does such a thing exist, and if not, can it? How can we ensure we go straight from stable to EOL for these projects?
As a separate point, we may wish to explore removing stable branches entirely for these projects. Open to input on whether this is even possible, or if their removal would have serious issues for folks.
Stable branches are not just about supported OpenStack versions, it's also about versions of the SDK/CLI itself. If you can commit to basically never have breaking changes, you can do without stable branches. Otherwise, a nasty situation may arise when you fix, say, a security bug, but people on 2.X.Y need to update to 4.A.B to pick it up, potentially making unwanted changes to their code. Dmitry
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/openstacksdk/+/911660 [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintai...
On Mon, Apr 22, 2024, at 10:48 AM, Dmitry Tantsur wrote:
Hi,
A comment on the separate point.
On 4/22/24 18:45, Stephen Finucane wrote:
o/
I've noticed that a variety of SDK-related projects have had 'Update .gitreview for unmaintained/wallaby' patches proposed against them, e.g [1]. I'm not sure this makes much sense. Both SDK and OSC are designed to work against any version of OpenStack so there's hardly a reason to keep stable branches around, let alone the unmaintained branches. I took a look through the Project Team Guide docs [2] but while I can find info on opting-in to keep older unmaintained branches around, I can't find any info on opting-out of their creation altogether.
That brings me to my question: does such a thing exist, and if not, can it? How can we ensure we go straight from stable to EOL for these projects?
As a separate point, we may wish to explore removing stable branches entirely for these projects. Open to input on whether this is even possible, or if their removal would have serious issues for folks.
Stable branches are not just about supported OpenStack versions, it's also about versions of the SDK/CLI itself. If you can commit to basically never have breaking changes, you can do without stable branches. Otherwise, a nasty situation may arise when you fix, say, a security bug, but people on 2.X.Y need to update to 4.A.B to pick it up, potentially making unwanted changes to their code.
You can defer the creation of branches until the point in time where they become necessary though. They can also be short lived to address specific problems rather than setting the expectation for a long lived stable branch.
Dmitry
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/openstacksdk/+/911660 [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintai...
On Mon, Apr 22, 2024 at 11:24 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Apr 22, 2024, at 10:48 AM, Dmitry Tantsur wrote:
Hi,
A comment on the separate point.
On 4/22/24 18:45, Stephen Finucane wrote:
o/
I've noticed that a variety of SDK-related projects have had 'Update .gitreview for unmaintained/wallaby' patches proposed against them, e.g [1]. I'm not sure this makes much sense. Both SDK and OSC are designed to work against any version of OpenStack so there's hardly a reason to keep stable branches around, let alone the unmaintained branches. I took a look through the Project Team Guide docs [2] but while I can find info on opting-in to keep older unmaintained branches around, I can't find any info on opting-out of their creation altogether.
That brings me to my question: does such a thing exist, and if not, can it? How can we ensure we go straight from stable to EOL for these projects?
As a separate point, we may wish to explore removing stable branches entirely for these projects. Open to input on whether this is even possible, or if their removal would have serious issues for folks.
Stable branches are not just about supported OpenStack versions, it's also about versions of the SDK/CLI itself. If you can commit to basically never have breaking changes, you can do without stable branches. Otherwise, a nasty situation may arise when you fix, say, a security bug, but people on 2.X.Y need to update to 4.A.B to pick it up, potentially making unwanted changes to their code.
You can defer the creation of branches until the point in time where they become necessary though. They can also be short lived to address specific problems rather than setting the expectation for a long lived stable branch.
When did this become the case? I guess I mean, I realize it has always been the case with git, but is it the case for OpenStack? When there has been a need in the past, the OpenStack release team rejected the idea. Granted, that was not a recent interaction, but if there has been a change in stance to enable the needful then excellent. If there has not been a change in stance/approach from the release team, then the idea of after the fact when the need arrives becomes a distraction we should be careful of focusing on.
Dmitry
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/openstacksdk/+/911660 [2]
https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintai...
On Mon, Apr 22, 2024, at 11:37 AM, Julia Kreger wrote:
On Mon, Apr 22, 2024 at 11:24 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Apr 22, 2024, at 10:48 AM, Dmitry Tantsur wrote:
Hi,
A comment on the separate point.
On 4/22/24 18:45, Stephen Finucane wrote:
o/
I've noticed that a variety of SDK-related projects have had 'Update .gitreview for unmaintained/wallaby' patches proposed against them, e.g [1]. I'm not sure this makes much sense. Both SDK and OSC are designed to work against any version of OpenStack so there's hardly a reason to keep stable branches around, let alone the unmaintained branches. I took a look through the Project Team Guide docs [2] but while I can find info on opting-in to keep older unmaintained branches around, I can't find any info on opting-out of their creation altogether.
That brings me to my question: does such a thing exist, and if not, can it? How can we ensure we go straight from stable to EOL for these projects?
As a separate point, we may wish to explore removing stable branches entirely for these projects. Open to input on whether this is even possible, or if their removal would have serious issues for folks.
Stable branches are not just about supported OpenStack versions, it's also about versions of the SDK/CLI itself. If you can commit to basically never have breaking changes, you can do without stable branches. Otherwise, a nasty situation may arise when you fix, say, a security bug, but people on 2.X.Y need to update to 4.A.B to pick it up, potentially making unwanted changes to their code.
You can defer the creation of branches until the point in time where they become necessary though. They can also be short lived to address specific problems rather than setting the expectation for a long lived stable branch.
When did this become the case?
I guess I mean, I realize it has always been the case with git, but is it the case for OpenStack? When there has been a need in the past, the OpenStack release team rejected the idea. Granted, that was not a recent interaction, but if there has been a change in stance to enable the needful then excellent. If there has not been a change in stance/approach from the release team, then the idea of after the fact when the need arrives becomes a distraction we should be careful of focusing on.
I can't speak to OpenStack's policies I'm merely pointing out that this is possible with the tooling that we have (git, gerrit, etc). This thread is a discussion on changing policy so seems like we shouldn't ignore an option simply because another policy might need to change. Instead we should discuss that and improve our processes if it makes sense to do so.
Dmitry
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/openstacksdk/+/911660 [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintai...
On Mon, Apr 22, 2024 at 11:41 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Apr 22, 2024 at 11:24 AM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Apr 22, 2024, at 10:48 AM, Dmitry Tantsur wrote:
Hi,
A comment on the separate point.
On 4/22/24 18:45, Stephen Finucane wrote:
o/
I've noticed that a variety of SDK-related projects have had 'Update .gitreview for unmaintained/wallaby' patches proposed against them, e.g [1]. I'm not sure this makes much sense. Both SDK and OSC are designed to work against any version of OpenStack so there's hardly a reason to keep stable branches around, let alone the unmaintained branches. I took a look through the Project Team Guide docs [2] but while I can find info on opting-in to keep older unmaintained branches around, I can't find any info on opting-out of their creation altogether.
That brings me to my question: does such a thing exist, and if not, can it? How can we ensure we go straight from stable to EOL for these projects?
As a separate point, we may wish to explore removing stable branches entirely for these projects. Open to input on whether this is even possible, or if their removal would have serious issues for folks.
Stable branches are not just about supported OpenStack versions, it's also about versions of the SDK/CLI itself. If you can commit to basically never have breaking changes, you can do without stable branches. Otherwise, a nasty situation may arise when you fix, say, a security bug, but people on 2.X.Y need to update to 4.A.B to pick it up, potentially making unwanted changes to their code.
You can defer the creation of branches until the point in time where
On Mon, Apr 22, 2024, at 11:37 AM, Julia Kreger wrote: they become necessary though. They can also be short lived to address specific problems rather than setting the expectation for a long lived stable branch.
When did this become the case?
I guess I mean, I realize it has always been the case with git, but is it the case for OpenStack? When there has been a need in the past, the OpenStack release team rejected the idea. Granted, that was not a recent interaction, but if there has been a change in stance to enable the needful then excellent. If there has not been a change in stance/approach from the release team, then the idea of after the fact when the need arrives becomes a distraction we should be careful of focusing on.
I can't speak to OpenStack's policies I'm merely pointing out that this is possible with the tooling that we have (git, gerrit, etc). This thread is a discussion on changing policy so seems like we shouldn't ignore an option simply because another policy might need to change. Instead we should discuss that and improve our processes if it makes sense to do so.
Well said, and I agree completely! Thanks!
Dmitry
Cheers, Stephen
[1] https://review.opendev.org/c/openstack/openstacksdk/+/911660 [2]
https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintai...
participants (5)
-
Clark Boylan
-
Dmitry Tantsur
-
Ghanshyam Mann
-
Julia Kreger
-
Stephen Finucane