Open Stack

> > We seem to be unable to address some key issues in the software we
> > produce, and part of it is due to strategic contributors (and core
> > reviewers) being overwhelmed just trying to stay afloat of what's
> > happening. For such projects, is it time for a pause ? Is it time to
> > define key cycle goals and defer everything else ?
> 
> I think it's quite reasonable for a project to set aside some time to
> focus on stability, whether that is a whole release cycle or just a
> milestone. However, I think your question here is more about
> OpenStack-wide issues, and how we enco^D^D^D^D whether we can require
> integrated projects that are seen as having gate-affecting instability
> to pause and address that.
> 
> > On the integrated release side, "more projects" means stretching our
> > limited strategic resources more. Is it time for the Technical Committee
> > to more aggressively define what is "in" and what is "out" ? If we go
> > through such a redefinition, shall we push currently-integrated projects
> > that fail to match that definition out of the "integrated release" inner
> > circle ?
> 
> "The integrated release" is an overloaded term at the moment. Outside
> of the developer community, I see it often cited as a blessing of a
> project's legitimacy and production-worthiness. While I feel that a
> non-production-ready project should not be "in the integrated
> release", this has not been upheld as a litmus test for integration in
> the past. Also, this does not imply that non-integrated projects
> should not be used in production. I've lost track of how many times
> I've heard someone say, "Why would I deploy Ironic when it hasn't
> graduated yet."
> 
> Integration is foremost an artifact of our testing and development
> processes -- an indication that a project has been following the
> release cadence, adheres to cross-project norms, is ready for
> cogating, and can be counted on to produce timely and stable builds at
> release time. This can plainly be seen by looking at the criteria for
> incubation and integration in our governance repo [1]. As written
> today, this does not have anything to do with the technical merit or
> production-worthiness of a project. It also does not have anything to
> do with what "layer" the project sits at -- whether it is IaaS, PaaS,
> or SaaS does not dictate whether it can be integrated.
> 
> The TC has begun to scrutinize new projects more carefully on
> technical grounds, particularly since some recently-integrated
> projects have run into scaling limitations that have hampered their
> adoption. I believe this sort of technical guidance (or curation, if
> you will) is an essential function of the TC. We've learned that
> integration bestows legitimacy, as well as assumptions of stability,
> performance, and scalability, upon projects which are integrated.
> While that wasn't the intent, I think we need to accept that that is
> where we stand. We will be faced with some hard decisions regarding
> projects, both incubated and already integrated, which are clearly not
> meeting those expectations today.

How does this relate to the recent gap analysis undertaken by the
TC for already integrated projects, in order to measure their status
against the steadily rising bar for integration?

That aforementioned process is actually still ongoing, with the TC
doing progress reviews against the projects' action plans throughout
the Juno cycle.

Cheers,
Eoghan