Can neutron-fwaas project be revived?

Lajos Katona katonalala at gmail.com
Thu Jan 20 09:07:35 UTC 2022


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
>  >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220120/c0cd9227/attachment.htm>


More information about the openstack-discuss mailing list