On 21/01/16 11:22 +0000, Daniel P. Berrange wrote:
On Wed, Jan 20, 2016 at 01:23:02PM -0430, Flavio Percoco wrote:Greetings,At the Tokyo summit, we discussed OpenStack's development themes in a cross-project session. In this session a group of folks started discussing what topics the overall community could focus on as a shared effort. One of the things that was raised during this session is the need of having cycles to stabilize projects. This was brought up by Robert Collins again in a meeting[0] the TC had right after the summit and no much has been done ever since. Now, "stabilization Cycles" are easy to dream about but really hard to do and enforce. Nonetheless, they are still worth a try or, at the very least, a thought. I'll try to go through some of the issues and benefits a stabilization cycle could bring but bear in mind that the lists below are not exhaustive. In fact, I'd love for other folks to chime in and help building a case in favor or against this. Negative(?) effects =================== - Project won't get new features for a period of time Economic impact on developers(?) - It was mentioned that some folks receive bonuses for landed features - Economic impact on companies/market because no new features were added (?) - (?)It will push more development into non-upstream vendor private branches.Positive effects ================ - Focus on bug fixing - Reduce review backlog - Refactor *existing* code/features with cleanups - Focus on multi-cycle features (if any) and complete those - (?)I don't think the idea of stabalization cycles would really have such a positive effect, certainly not while our release cycle is 6 months in length. If you say the next cycle is primarily stabalization, then what you are in effect saying is that people have to wait 12 months for their desired new feature. In the fast moving world of cloud, I don't think that is a very credible approach. Even with our current workflow, where we selectively approve features for cycles, we have this impact of forcing people to wait 12 months, or more, for their features.
++ This is one of the main concerns and perhaps the reason why I don't think it should be all-or-nothing. It should be perfectly fine for teams to have stabilization milestones, FWIW.
In the non-stabalization cycle, we're not going to be able to merge a larger number of features than we already do today. So in effect we'll have 2 cycles worth of features being proposed for 1 cycle. When we inevitably reject moany of those features they'll have to wait for the next non-stabalization cycle, which means 18-24 months delay. Of course in reality this kind of delay won't happen. What will instead happen is that various vendors will get pressure from their customers/partners and their local branches of openstack packages will fork & diverge even further from upstream than they already do today. So while upstream branch will be "stabalized", most users will probably get a *less* stable release because they'll be using a branch from vendors with a tonne of non-upstream stuff added.
I would expect these vendors to (slowly?) push their changes upstream. It'd take time but it should certainly happen.
In addition having a stablization cycle will give the impression that the following cycle is a non-stable one and likely cause more distruption by pushing lots of features in at one time. Instead of having a master branch which has an approximately constant level of stabalization, you'll create a situation where it fluctuates significantly, which is clearly worse for people doing continuous deployment. I think it is important to have the mindset that master should *always* be considered stable - we already have this in general and it is one of the success points of openstack's development model IMHO. The idea of stabalization cycles is a step backwards
Perhaps, it is being presented the wrong way. I guess the main point here is how ca we communicate that we'd like to take some time to clean-up the mess we have in some projects. How can projects ask their team to put more efforts on tackling technical debt rather than pushing the new sexy thing? I could consider Mitaka as a stabilization cycle for Glance (except for the upload path refactor spec). The team has spent quite some time on working out a way to improve that workflow. Few other specs have been implemented but nothing major, TBH (talking about Glance here, not the other components). What I mean is, that I don't consider a stabilization cycle a full heads-down on bug fixing cyle but rather a cycle where no major features are approved. What unfortunatelly happens when these kind of cycles are announced or planned is that contributions vanish and they are routed to places where new features land. That should perhaps be an indicator of how good/bad these cycles are. *shurgs*
I still believe that if you want to improve stabality of the codebase, we'd be better off moving to a shorter development cycle. Even the 6 month cycle we have today is quite "lumpy" in terms of what kind of work happens from month to month. If we moved to a 2 month cycle, I think it would relieve pressure to push in features quickly before freeze, because people would know they'd have another opportunity very soon, instead of having to wait 6+ months. I've previously suggested that here: http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html
Whether we move to shorter cycles or not, I still think there's a way we can do this now. Again, I don't believe these cycles should be all-or-nothing and teams should feel free to dedicate as much time to this as they want (and some do already). Flavio
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 :|
-- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
