Can neutron-fwaas project be revived?

Ghanshyam Mann gmann at ghanshyammann.com
Fri Jan 28 19:08:44 UTC 2022


 ---- On Fri, 28 Jan 2022 10:59:28 -0600 Lajos Katona <katonalala at gmail.com> wrote ----
 > 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.2022-01-28-14.00.log.html#l-14
 > The process for Stadium projects:https://docs.openstack.org/neutron/latest/contributor/stadium/governance.html
 > Thanks for stepping in to maintaining and developing neutron-fwaas.

Thanks lajoskatona, neutron team for reconsidering it.

@ Inspur team,
Plese propose the revert of deprecation of neutron-fwaas in governance. and after that we can
setup the project-config, jobs things there.

-gmann

 > RegardsLajos Katona (lajoskatona)
 > 
 > 
 > Lajos Katona <katonalala at 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 at ghanshyammann.com> ezt írta (időpont: 2022. jan. 19., Sze, 15:02):
 >  ---- On Wed, 19 Jan 2022 02:23:39 -0600 Lajos Katona <katonalala at gmail.com> wrote ----
 >  > 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 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 at 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
 >  >                              
 > 	



More information about the openstack-discuss mailing list