> -----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 forward > > On 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. My 2 Euro cents, Erno > Cheers, > Flavio > > -- > @flaper87 > Flavio Percoco __________________________________________________________________________ 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
