Open Stack

Sorry where I said  
"Specially for dependencies and cross version dependencies.”
I meant
Specially for dependencies and cross version differences.


Miguel Ángel Ajo


On Tuesday, 24 de February de 2015 at 12:06, Miguel Ángel Ajo wrote:

> 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/864a4a4f/attachment.html>