On 27/01/16 11:00 +0000, Kuvaja, Erno wrote:
-----Original Message----- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Monday, January 25, 2016 3:07 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forwardOn 20/01/16 13:23 -0430, Flavio Percoco wrote: >Thoughts? Feedback? Hey Folks, Thanks a lot for the feedback. Great comments and proposals in the many replies. I've gone through the whole thread and collected the most common feedback. Here's the summary: - The general idea of planning some sort of stabilization for a project is good but considering a cycle for it is terrible. It'd be easier if development cycles would be shorter but the 6-month based development cycles don't allow for planning this properly. - Therefore, milestones are more likely to be good for this but there has to be a good plan. What will happen with on-going features? How does a project decide what to merge or not? Is it really going to help with reviews/bugs backlog? or would this just increase the bakclog? - We shouldn't need any governance resolution/reference for this. Perhaps a chapter/section on the project team guide should do it. - As other changes in the commuity, it'd be awesome to get feedback from a project doing this before we start encouraging other projects to do the same. I'll work on adding something to the project team guide that covers the above points. did I miss something? Anything else that we should add and or consider?Sorry for jumping the gun this late, but I have been thinking about this since your first e-mail and one thing bothers me. Don't we have stabilization cycle for each release starting right from the release? In my understanding this is exactly what the Stable releases Support Phase I is accepting bug fixes but no new features. After 6 months the release is moved to Phase II where only critical and security fixes are accepted; I think this is good example of stabilization cycle and the output is considered solid. All concerns looked at I think the big problem really is to get the people working on these cycles. Perhaps we should encourage more active maintenance on our stable branches and see then what we can bring from that to our development branch expertise and knowledge wise. While I'm not huge believer of constant agile development, this is one of those things that needs to be lived with and I think stable branches are our best bet for stabilization work (specifically when that work needs to land to master first). For long term refactoring I'd like to see us using more feature branches so we can keep doing the work without releasing it before it's done.
So, I think what confused most people in the thread is the title itself. The title is Stabilization Cycles but it really means "clean up the mess we have in the code base.... including bugs". We can't address technical debt in stable branches other than bug fixes. Refactors are rejected and, of course, no breaking changes allowed. While your thoughts are correct, as we should encourage more folks to contribute to stable branches and fix bugs there, it's true that there are not enough people in every project to keep master moving forward and focusing on bugs for master *and* stable branches at the same time. Ideally, most of that "Stabilization" work should be backported to stable branches as well. Flavio
My 2 Euro cents, ErnoCheers, Flavio -- @flaper87 Flavio Percoco
-- @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
