On 20/01/16 18:38 +0000, Ian Cordasco wrote:
-----Original Message----- From: Flavio Percoco <fla...@redhat.com> Reply: Flavio Percoco <fla...@redhat.com>, OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Date: January 20, 2016 at 11:57:56 To: openstack-dev@lists.openstack.org <openstack-dev@lists.openstack.org> Subject: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forwardGreetings, 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 (?) - (?) 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 - (?) A stabilization cycle, as it was also discussed in the aforementioned meeting[0], doesn't need to be all or nothing. For instance, it should be perfectly fine for a project to say that a project would dedicate 50% of the cycle to stabilization and the rest to complete some pending features. Moreover, each project is free to choose when/if a stabilization cycle would be good for it or not. For example, the Glance team is currently working on refactoring the image import workflow. This is a long term effort that will require at least 2 cycles to be completed. Furthermore, it's very likely these changes will introduce bugs and that will require further work. If the Glance team would decide (this is not an actual proposal... yet :) to use Newton as a stabilization cycle, the team would be able to focus all its forces on fixing those bugs, completing the feature and tackling other, long-term, pending issues. In the case of Glance, this would impact *only glance* and not other projects under the Glance team umbrella like glanceclient and glance_store. In fact, this would be a perfect time for the glance team to dedicate time to improving glanceclient and catch up with the server side latest changes. So, the above sounds quite vague, still but that's the idea. This email is not a formal proposal but a starting point to move this conversation forward. Is this something other teams would be interested in? Is this something some teams would be entirely against? Why? From a governance perspective, projects are already empowered to do this and they don't (and won't) need to be granted permission to have stabilization cycles. However, the TC could work on formalizing this process so that teams have a reference to follow when they want to have one. For example, we would have to formalize how projects announce they want to have a stabilization cycle (I believe it should be done before the mid-term of the ongoing cycle). Thoughts? Feedback? Flavio [0] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-11-03-20.07.log.html (20:47:02)I think this is a solid proposal but I'm not sure what (if anything) the TC needs to do about this. This is something most non-corporate open source projects do (and even some corporate open source projects). It's the natural life-cycle of any software project (that we ship a bunch of things and then focus on stability). Granted, I haven't seen much of a focus on it in OpenStack but that's a different story.
Given the importance of this, which I believe is high, I think the TC can help establishing some guidelines and encouraging projects to do this often enough by expresing an opinion. There's nothing to do from a governance perspective - as I mentioned in my first email - but I do think we need to make this a cross-project effort, at the very least. Syncing with the release team will also be required, especially to find a way to communicate this properly to users. Cheers, Flavio
That said, I'd like to see a different release cadence for cycles that are "stabilization cycles". We, as a community, are not using minor version numbers. During a stabilization cycle, I would like to see master be released around the 3 milestones as X.1.0, X.2.0, X.3.0. If we work that way, then we'll be able to avoid having to backport a lot of work to the X.0 series and while we could support X.0 series with specific backports, it would avoid stressing our already small stable teams. My release strategy, however, may cause more stress for downstream packages though. It'll cause them to have to decide what and when to package and to be far more aware of each project's current development cycle. I'm not sure that's positive. -- Ian Cordasco __________________________________________________________________________ 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
-- @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
