Open Stack

Hello Elõd:

As you said, we are no longer sending patches for Train. In the last four
months, we have sent only two patches changing the code (apart from other
testing patches). I proposed the EOL of Train because of this and the extra
cost involved in maintaining older versions, regardless of this CI status.
In any case, I'll propose this topic in the PTG tomorrow, considering
leaving only the Neutron Train branch as EM and closing the rest of the
projects.

Regards.

On Mon, Mar 27, 2023 at 3:25 PM Elõd Illés <elod.illes at est.tech> wrote:

> Hi,
>
> (First of all, I'm writing this as stable maintainer, someone who
> was there when the 'Extended Maintenance' process was formulated
> in the first place)
>
> As far as I understand, neutron's stable/train gate is still fully
> operational. I also know that backporting every bug fix to stable
> branches is time and resource consuming, and the team does not have /
> want to spend time on this anymore. Between EOL'ing and backporting
> every single bug fix, there are another levels of engagement.
>
> What I want to say is: what if stable/train of neutron is kept open as
> long as the gate is functional, to give people the possibility for
> cooperation, give the opportunity to test backports, bug fixes on
> upstream CI for stable/train.
>
> There are two extremity in opinions about how far back we should
> maintain things:
> 1) we should keep only open the most recent stable release to free up
>    resources, and minimize maintenance cost
> 2) we should keep everything open, even the very old stable branches,
>    where even the gate jobs are not functional anymore, to give space
>    for collaboration in fixing important bugs (like security bugs)
>
> I think the right way is somewhere in the middle: as long as the gate
> is functional we can keep a branch open, for *collaboration*.
> I understand if most active neutron team members do not propose
> backports to stable/train anymore. Some way, this is acceptable
> according to Extended Maintenance process: it is not "fully maintained",
> rather there is still the possibility to do *some* maintenance.
>
> (Note, that I'm mostly talking about neutron. Stadium projects, that
> have broken gates (even on master branch), I support the EOL'ing)
>
> What do you think about the above suggestion?
>
> Thanks,
>
> Előd
> irc: elodilles
> ------------------------------
> *From:* Rodolfo Alonso Hernandez <ralonsoh at redhat.com>
> *Sent:* Thursday, March 16, 2023 5:15 PM
> *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
> *Subject:* [neutron][release] Proposing transition to EOL Train (all
> Neutron related projects)
>
> Hello:
>
> I'm sending this mail in advance to propose transitioning Neutron and all
> related projects to EOL. I'll propose this topic too during the next
> Neutron meeting.
>
> The announcement is the first step [1] to transition a stable branch to
> EOL.
>
> The patch to mark these branches as EOL will be pushed in two weeks. If
> you have any inconvenience, please let me know in this mail chain or in IRC
> (ralonsoh, #openstack-neutron channel). You can also contact any Neutron
> core reviewer in the IRC channel.
>
> Regards.
>
> [1]
> https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230327/6dbb1b25/attachment-0001.htm>