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@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@redhat.com> *Sent:* Thursday, March 16, 2023 5:15 PM *To:* openstack-discuss <openstack-discuss@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-li...