Open Stack

Excerpts from Thierry Carrez's message of 2018-08-02 10:58:53 +0200:
> Tony Breeds wrote:
> > [...]
> > There are 8 projects without candidates, so according to this
> > resolution[1], the TC will have to decide how the following
> > projects will proceed: Dragonflow, Freezer, Loci, Packaging_Rpm,
> > RefStack, Searchlight, Trove and Winstackers.
> 
> Here is my take on that...
> 
> Packaging_Rpm has a late candidate (Dirk Mueller). We always have a few 
> teams per cycle that miss the election call, that would fall under that.
> 
> Trove had a volunteer (Dariusz Krol), but that person did not fill the 
> requirements for candidates. Given that the previous PTL (Zhao Chao) 
> plans to stay around to help onboarding the new contributors, I'd 
> support appointing Dariusz.
> 
> I suspect Freezer falls in the same bucket as Packaging_Rpm and we 
> should get a candidate there. I would reach out to caoyuan see if they 
> would be interested in steeping up.
> 
> LOCI is also likely in the same bucket. However, given that it's a 
> deployment project, if we can't get anyone to step up and guarantee some 
> level of currentness, we should consider removing it from the "official" 
> list.
> 
> Dragonflow is a bit in the LOCI case. It feels like a miss too, but if 
> it's not, given that it's an add-on project that runs within Neutron, I 
> would consider removing it from the "official" list if we can't find 
> anyone to step up.
> 
> For Winstackers and Searchlight, those are low-activity teams (18 and 13 
> commits), which brings the question of PTL workload for feature-complete 
> projects.

Even for feature-complete projects we need to know how to reach the
maintainers, otherwise I feel like we would consider the project
unmaintained, wouldn't we?

> 
> Finally, RefStack: I feel like this should be wrapped into an 
> Interoperability SIG, since that project team is not producing 
> "OpenStack", but helping fostering OpenStack interoperability. Having 
> separate groups (Interop WG, RefStack) sounds overkill anyway, and with 
> the introduction of SIGs we have been recentering project teams on 
> upstream code production.
>