<div dir="ltr">Hi,<div><br></div><div>Thanks for the advice.<br><div>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.</div></div><div>If there's easier ways for volunteers to keep it maintained other than forking it to x/ namespace that would be really helpful.</div><div><br></div><div>Lajos Katona (lajoskatona)</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> ezt írta (időpont: 2022. jan. 18., K, 18:58):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2022-01-18 10:49:48 -0600 (-0600), Ghanshyam Mann wrote:<br>
[...]<br>
> As discussed in project-config change[1], you or neutron folks can<br>
> propose the retirement now itself (considering there is no one to<br>
> maintain/release stable/victoria for new bug fixes) and TC will<br>
> merge it as per process. After that, creating it in x/ namespace<br>
> will be good to do.<br>
[...]<br>
<br>
Looking at this from a logistical perspective, it's a fair amount of<br>
churn in code hosting as well as unwelcoming to the new volunteers,<br>
compared to just leaving the repository where it is now and letting<br>
them contribute to it there. If the concern is that the Neutron team<br>
doesn't want to retain responsibility for it while they evaluate the<br>
conviction of the new maintainers for eventual re-inclusion, then<br>
the TC would be well within its rights to declare that the<br>
repository can remain in place while not having it be part of the<br>
Neutron team's responsibilities.<br>
<br>
There are a number of possible solutions, ranging from making a new<br>
category of provisional deliverable, to creating a lightweight<br>
project team under the DPL model, to declaring it a pop-up team with<br>
a TC-owned repository. There are repositories within the OpenStack<br>
namespace which are not an official part of the OpenStack<br>
coordinated release, after all. Solutions which don't involve having<br>
the new work take place somewhere separate, and the work involved in<br>
making that separate place, which will simply be closed down as<br>
transient cruft if everything goes as desired.<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div>