Open Stack

On Tue, Feb 24, 2015 at 2:59 AM, Daniel P. Berrange <berrange at redhat.com>
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
>
>
Nothing like having to concurrent threads on the same thing with very
similar subjects.

[openstack-dev] [all] Re-evaluating the suitability of the 6 month release
cycle

vs

[openstack-dev][stable][all] Revisiting the 6 month release cycle

I'll respond to your proposal, on the other thread.



> > 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.
>

Make sense


>
> 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
> 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/6a89eea8/attachment.html>