Open Stack

On 23/02/15 19:14, Joe Gordon wrote:
> Was:
> http://lists.openstack.org/pipermail/openstack-dev/2015-February/057578.html
>
> There has been frustration with our current 6 month development cadence.
> This is an attempt to explain those frustrations and propose a very
> rough outline of a possible alternative.
>
>
> Currently we follow a 6 month release cadence, with 3 intermediate
> milestones (6 weeks apart), as explained here:
> https://wiki.openstack.org/wiki/Kilo_Release_Schedule
>
>
> Current issues
>
>   * 3 weeks of feature freeze for all projects at the end of each cycle
>     (3 out of the 26 feature blocked)
>   * 3 weeks of release candidates. Once a candidate is cut development
>     is open for next release. While this is good in theory, not much
>     work actually starts on next release.
>   * some projects have non priority feature freezes and at Milestone 2
>     (so 9 out of 26 weeks restricted in those projects)
>   * vicious development circle
>       o vicious circle:
>           + big push right to land lots of features right before the release
>           + a lot of effort is spent getting the release ready
>           + after the release people are a little burnt out and take it
>             easy until the next summit
>           + Blueprints have to be re-discussed and re-approved for the
>             next cycle

I'm sure there's a good reason for this one that I'm not aware of, but 
it certainly sounds a lot like declaring a war of attrition against a 
project's own contributors.

If core teams think that a design that they previously approved needs to 
change because of other changes _they_ approved in the previous release 
cycle or a decision _they_ made during the design summit, the onus 
should be on _them_ to actively make the change (even if that's as 
simple as proposing a patch deleting *a* previously-approved spec - not 
the whole lot en masse). To delete everything by default and force the 
contributor to get it reapproved is tantamount to handing them a shovel 
and forcing them to shift the goalposts themselves. It's flirting with 
the line between poor policy and outright evil.

>           + makes it hard to land blueprints early in the cycle casing
>             the bug rush at the end of the cycle, see step 1
>       o Makes it hard to plan things across a release
>       o This actually destabilizes things right as we go into the
>         stabilization period (We actually have great data on this too)
>       o Means postponing blueprints that miss a deadline several months

I'm yet to be convinced by the solution offered here, but I do think 
this is a fairly accurate description of the problem. I always tell 
folks that if you want big features to land in the next release, you 
have to start working on them as soon as you can finish up on any 
release blockers and well before Summit. Mostly that month feels like 
dead time, though.

Sometimes I daydream about what it would be like if we had the design 
summit a few weeks _before_ the release instead of after. Usually I snap 
out of it when I remember the downsides, like having developers under 
pressure to fix bugs at the same time as the design summit, or not 
having a shiny new release to trumpet at the conference, or everyone 
getting excited about new feature discussions and not working on urgent 
bugs when they get back. Still, I keep thinking about it...

cheers,
Zane.