Open Stack

Excerpts from Thierry Carrez's message of 2014-08-13 02:54:58 -0700:
> Rochelle.RochelleGrober wrote:
> > [...]
> > So, with all that prologue, here is what I propose (and please consider proposing your improvements/changes to it).  I would like to see for Kilo:
> > 
> > - IRC meetings and mailing list meetings beginning with Juno release and continuing through the summit that focus on core project needs (what Thierry call "strategic") that as a set would be considered the primary focus of the Kilo release for each project.  This could include high priority bugs, refactoring projects, small improvement projects, high interest extensions and new features, specs that didn't make it into Juno, etc.
> > - Develop the list and prioritize it into "Needs" and "Wants." Consider these the feeder projects for the two runways if you like.  
> > - Discuss the lists.  Maybe have a community vote? The vote will "freeze" the list, but as in most development project freezes, it can be a soft freeze that the core, or drivers or TC can amend (or throw out for that matter).
> > [...]
> 
> One thing we've been unable to do so far is to set "release goals" at
> the beginning of a release cycle and stick to those. It used to be
> because we were so fast moving that new awesome stuff was proposed
> mid-cycle and ends up being a key feature (sometimes THE key feature)
> for the project. Now it's because there is so much proposed noone knows
> what will actually get completed.
> 
> So while I agree that what you propose is the ultimate solution (and the
> workflow I've pushed PTLs to follow every single OpenStack release so
> far), we have struggled to have the visibility, long-term thinking and
> discipline to stick to it in the past. If you look at the post-summit
> plans and compare to what we end up in a release, you'll see quite a lot
> of differences :)
> 

I think that shows agility, and isn't actually "a problem". 6 months
is quite a long time in the future for some business models. Strategic
improvements for the project should be able to stick to a 6 month
schedule, but companies will likely be tactical about where their
developer resources are directed for feature work.

The fact that those resources land code upstream is one of the greatest
strengths of OpenStack. Any potential impact on how that happens should
be carefully considered when making any changes to process and
governance.