Quoting Flavio Percoco (2016-01-25 16:06:36) > 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?
There is still a option about having a sorter development cycle. As Thierry said in a previous message in this thread: "It is not entirely impossible that due to events organization we'll accidentally have a shorter cycle (say, 4 months instead of 6) in the future here and there. I could totally see projects take advantage of such a short cycle to place a "stabilization cycle" or another limited-feature-addition period." Would be nice to have more info about it. I guess if he mentioned it, it's because they foundation already faced that possibility. Ghe Rivero > - 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? > > 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 __________________________________________________________________________ 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