Open Stack

IMHO, killing releases, or shortening the cycles, would add up a lot more  
of work to stable maintainers and harder to track cross project dependencies.

Specially for dependencies and cross version dependencies.

Also deployment changes will make everybody’s life harder.

IMO it’s a matter of better coordination, and shortening the spec submission
timeframe, even moving it back to the end of the previous cycle, so it’s clear
what should be the community focus for a certain cycle.

The neutron driver team & PTL have done a good work in this regard.  

Miguel Ángel Ajo


On Tuesday, 24 de February de 2015 at 11:59, Daniel P. Berrange wrote:

> On Mon, Feb 23, 2015 at 04:14:36PM -0800, 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
> > - 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
> > - makes it hard to land blueprints early in the cycle casing the
> > bug rush at the end of the cycle, see step 1
> > - Makes it hard to plan things across a release
> > - This actually destabilizes things right as we go into the
> > stabilization period (We actually have great data on this too)
> > - Means postponing blueprints that miss a deadline several months
> >  
> >  
> > Requirements for a new model
> >  
> > - Keep 6 month release cadence. Not everyone is willing to deploy from
> > trunk
> > - Keep stable branches for at least 6 months. In order to test upgrades
> > from the last stable branch, we need a stable branch to test against
> > - Keep supporting continuous deployment. Some people really want to
> > deploy from trunk
> >  
> >  
> > What We can drop
> >  
> > - While we need to keep releasing a stable branch every 6 months, we
> > don't have to do all of our development planning around it. We can treat it
> > as just another milestone
> >  
> >  
> > I think a lot of the frustration with our current cadence comes out of the
> > big stop everything (development, planning etc.), and stabilize the release
> > process. Which in turn isn't really making things more stable. So I propose
> > we keep the 6 month release cycle, but change the development cycle from a
> > 6 month one with 3 intermediate milestones to a 6 week one with a milestone
> > at the end of it.
> >  
>  
>  
> You're solving some issues around developer experiance by letting developers
> iterate on a faster cycle which is something I agree with, but by keeping
> the 6 month release cycle I think you're missing the bigger opportunity here.
> Namely, the chance to get the features to the users faster, which is ultimtely
> the reason why contributors currently push us so hard towards the end of the
> release. I think we have to be more ambitious here and actually make the release
> cycle itself faster, putting it on a 2 month cycle. More detail about why I think
> this is needed is here:
>  
> http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html
>  
> > What this actually means:
> >  
> > - Stop approving blueprints for specific stable releases, instead just
> > approve them and target them to milestones.
> > - Milestones stop becoming Kilo-1, Kilo-2, Kilo-3 etc. and just
> > become 1,2,3,4,5,6,7,8,9 etc.
> > - If something misses what was previously known as Kilo-3 it has to
> > wait a week for what for milestone 4.
> > - Development focuses on milestones only. So 6 week cycle with say 1
> > week of stabilization, finish things up before each milestone
> > - Process of cutting a stable branch (planning, making the branch, doing
> > release candidates, testing etc.) is done by a dedicated stable branch
> > team. And it should be done based on a specific milestone
> > - Goal: Change the default development planning mode to ignore stable
> > branches, and allow for us to think of things in terms of the number of
> > milestones needed, not will it make the stable branch or not
> >  
> >  
> > Gotchas, questions etc:
> >  
> > - Some developers will still care about getting a feature into a
> > specific stable release, so we may still get a small rush for the milestone
> > before each stable branch
> > - Requires significantly more work from the stable maintenance team
> >  
>  
>  
> I think we can increase the release cycle to 2 months without impacting the
> stable team to any great extent. We simply don't have to provide stabel branches
> for every single release - compare with Linux, only a subset of major releases
> get stable branches & that generally works pretty well.
>  
> > - Naming the stable branches becomes less fun, as we refer to the stable
> > branches less
> > - Since planning is continuous 6 month cycle for summits becomes a
> > little strange. This is still an open ended question to me.
> >  
>  
>  
> Simply stop calling them (release) design summits and call them conferences.
> ie just have them be a forum for general developer & project collaboration &
> communication. I'm not saying turn them into a series of presentation slots,
> just don't portray them as the place where the next release is "designed",
> let them be a more flexible general purpose forum.
>  
> Regards,
> Daniel
> --  
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org -o- http://virt-manager.org :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
>  
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe (mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe)
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150224/f41e0768/attachment.html>