Can neutron-fwaas project be revived?
katonalala at gmail.com
Fri Jan 28 16:59:28 UTC 2022
Today Neutron drivers team again discussed the topic of the maintenance of
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:
The process for Stadium projects:
Thanks for stepping in to maintaining and developing neutron-fwaas.
Lajos Katona (lajoskatona)
Lajos Katona <katonalala at gmail.com> ezt írta (időpont: 2022. jan. 20., Cs,
> 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.
> 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
>> 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).
>> > 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, 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss