Excerpts from Flavio Percoco's message of 2016-01-20 13:23:02 -0430: > 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
As uncomfortable as it may be to tell another contributor "no" and realize that it will have a direct financial impact on them, we can't encourage a contribution model in which everyone is vying for their own special patches to land in order to get paid. That destroys our ability to look at the overall health of the project, and objectively examine the wisdom of adding (or removing) any given feature. It moves the issues we have with some vendor-specific drivers out of the driver space and into all of OpenStack, turning our open collaboration into competition. > - 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 I like the idea of teams taking the time to improve stability, whether that's 100% or 50% or 10% of the time in a given cycle. I also recognize that the community needs to make it very clear this is acceptable. Historically, we have done a better job with big process changes like this through experimentation, rather than trying to work them out in a way that will work for all projects. So I think the next step is for a project to volunteer to announce a stabilization cycle, and then we'll work out the details for that team as they go. And after the cycle, we'll hold a retrospective to talk about what went well and what would need to change, so that other teams can benefit from the experience. Doug > > > [0] > http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-11-03-20.07.log.html > (20:47:02) > __________________________________________________________________________ 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
