> > At the end of the day, that's probably going to mean saying No to more
> > things. Everytime I turn around everyone wants the TC to say No to
> > things, just not to their particular thing. :) Which is human nature.
> > But I think if we don't start saying No to more things we're going to
> > end up with a pile of mud that no one is happy with.
> 
> That we're being so abstract about all of this is frustrating. I get
> that no-one wants to start a flamewar, but can someone be concrete about
> what they feel we should say 'no' to but are likely to say 'yes' to?
> 
> 
> I'll bite, but please note this is a strawman.
>
> No:
> * Accepting any more projects into incubation until we are comfortable with
> the state of things again
> * Marconi
> * Ceilometer

Well -1 to that, obviously, from me.

Ceilometer is on track to fully execute on the gap analysis coverage
plan agreed with the TC at the outset of this cycle, and has an active
plan in progress to address architectural debt.
 
> Divert all cross project efforts from the following projects so we can focus
> our cross project resources. Once we are in a bitter place we can expand our
> cross project resources to cover these again. This doesn't mean removing
> anything.
> * Sahara
> * Trove
> * Tripleo

You write as if cross-project efforts are both of fixed size and
amenable to centralized command & control.

Neither of which is actually the case, IMO.

Additional cross-project resources can be ponied up by the large
contributor companies, and existing cross-project resources are not
necessarily divertable on command.

> Yes:
> * All integrated projects that are not listed above

And what of the other pending graduation request?

Cheers,
Eoghan

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to