On Tue, Feb 24, 2015 at 2:59 AM, Daniel P. Berrange <berra...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
