<div dir="ltr"><div>Hi,</div><div><br></div><div>I'm sorry for the inconvenience. I completely missed the nomination period. Is it possible to send in a late nomination for Dragonflow?</div><div></div><div><br></div><div>Thanks,</div><div>Omer Anson.<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 2 Aug 2018 at 11:59, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tony Breeds wrote:<br>
> [...]<br>
> There are 8 projects without candidates, so according to this<br>
> resolution[1], the TC will have to decide how the following<br>
> projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm,<br>
> RefStack, Searchlight, Trove and Winstackers.<br>
<br>
Here is my take on that...<br>
<br>
Packaging_Rpm has a late candidate (Dirk Mueller). We always have a few <br>
teams per cycle that miss the election call, that would fall under that.<br>
<br>
Trove had a volunteer (Dariusz Krol), but that person did not fill the <br>
requirements for candidates. Given that the previous PTL (Zhao Chao) <br>
plans to stay around to help onboarding the new contributors, I'd <br>
support appointing Dariusz.<br>
<br>
I suspect Freezer falls in the same bucket as Packaging_Rpm and we <br>
should get a candidate there. I would reach out to caoyuan see if they <br>
would be interested in steeping up.<br>
<br>
LOCI is also likely in the same bucket. However, given that it's a <br>
deployment project, if we can't get anyone to step up and guarantee some <br>
level of currentness, we should consider removing it from the "official" <br>
list.<br>
<br>
Dragonflow is a bit in the LOCI case. It feels like a miss too, but if <br>
it's not, given that it's an add-on project that runs within Neutron, I <br>
would consider removing it from the "official" list if we can't find <br>
anyone to step up.<br>
<br>
For Winstackers and Searchlight, those are low-activity teams (18 and 13 <br>
commits), which brings the question of PTL workload for feature-complete <br>
projects.<br>
<br>
Finally, RefStack: I feel like this should be wrapped into an <br>
Interoperability SIG, since that project team is not producing <br>
"OpenStack", but helping fostering OpenStack interoperability. Having <br>
separate groups (Interop WG, RefStack) sounds overkill anyway, and with <br>
the introduction of SIGs we have been recentering project teams on <br>
upstream code production.<br>
<br>
-- <br>
Thierry Carrez (ttx)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>