Hi, Today Neutron drivers team again discussed the topic of the maintenance of neutron-fwaas. The team agreed to include neutron-fwaas again to Neutron stadium, with the maintenance of Inspur and the guidance of Neutron core team, and with +2 rights to Inspur developers. The logs of the meeting: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2... The process for Stadium projects: https://docs.openstack.org/neutron/latest/contributor/stadium/governance.htm... Thanks for stepping in to maintaining and developing neutron-fwaas. Regards Lajos Katona (lajoskatona) Lajos Katona <katonalala@gmail.com> ezt írta (időpont: 2022. jan. 20., Cs, 10:07):
Hi, Neutron team is open to include projects to the stadium group (that was the feeling during the meeting also when we discussed this topic) if there is a stable maintainer team behind the project. So as you mentioned it would be easier to avoid the back and forth movement of fwaas if possible.
Lajos
Ghanshyam Mann <gmann@ghanshyammann.com> ezt írta (időpont: 2022. jan. 19., Sze, 15:02):
Hi, Thanks for the advice. The intention from the Neutron team was to make it clear that the team currently has no capacity to help the maintenance of neutron-fwaas, and can't help to maintain it.If there's easier ways for volunteers to keep it
---- On Wed, 19 Jan 2022 02:23:39 -0600 Lajos Katona < katonalala@gmail.com> wrote ---- maintained other than forking it to x/ namespace that would be really helpful.
Thanks Lajos,
Main point here is if it is maintained by current maintainer (inspur team or other developers) whether neutron team will consider that to be in added in neutron stadium?
If yes, then it will be extra work to move to x/ namespace now and then bring back to openstack/. If no, then moving to x/ namespace is good option or if maintainer want to be in openstack then we can discuss about a separate new project (but that needs more discussion on host much cost it adds).
-gmann
Lajos Katona (lajoskatona)
Jeremy Stanley <fungi@yuggoth.org> ezt írta (időpont: 2022. jan. 18., K, 18:58): On 2022-01-18 10:49:48 -0600 (-0600), Ghanshyam Mann wrote: [...]
As discussed in project-config change[1], you or neutron folks can propose the retirement now itself (considering there is no one to maintain/release stable/victoria for new bug fixes) and TC will merge it as per process. After that, creating it in x/ namespace will be good to do. [...]
Looking at this from a logistical perspective, it's a fair amount of churn in code hosting as well as unwelcoming to the new volunteers, compared to just leaving the repository where it is now and letting them contribute to it there. If the concern is that the Neutron team doesn't want to retain responsibility for it while they evaluate the conviction of the new maintainers for eventual re-inclusion, then the TC would be well within its rights to declare that the repository can remain in place while not having it be part of the Neutron team's responsibilities.
There are a number of possible solutions, ranging from making a new category of provisional deliverable, to creating a lightweight project team under the DPL model, to declaring it a pop-up team with a TC-owned repository. There are repositories within the OpenStack namespace which are not an official part of the OpenStack coordinated release, after all. Solutions which don't involve having the new work take place somewhere separate, and the work involved in making that separate place, which will simply be closed down as transient cruft if everything goes as desired. -- Jeremy Stanley