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#unmaintained
>> >>