On Thu, Aug 07, 2014 at 03:56:04AM -0700, Jay Pipes wrote: > On 08/07/2014 02:12 AM, Kashyap Chamarthy wrote: > >On Thu, Aug 07, 2014 at 07:10:23AM +1000, Michael Still wrote: > >>On Wed, Aug 6, 2014 at 2:03 AM, Thierry Carrez <thie...@openstack.org> > >>wrote: > >> > >>>We seem to be unable to address some key issues in the software we > >>>produce, and part of it is due to strategic contributors (and core > >>>reviewers) being overwhelmed just trying to stay afloat of what's > >>>happening. For such projects, is it time for a pause ? Is it time to > >>>define key cycle goals and defer everything else ? > > > >[. . .] > > > >>We also talked about tweaking the ratio of "tech debt" runways vs > >>'feature" runways. So, perhaps every second release is focussed on > >>burning down tech debt and stability, whilst the others are focussed > >>on adding features. > > > >>I would suggest if we do such a thing, Kilo should be a "stability' > >>release. > > > >Excellent sugestion. I've wondered multiple times that if we could > >dedicate a good chunk (or whole) of a specific release for heads down > >bug fixing/stabilization. As it has been stated elsewhere on this list: > >there's no pressing need for a whole lot of new code submissions, rather > >we focusing on fixing issues that affect _existing_ users/operators. > > There's a whole world of GBP/NFV/VPN/DVR/TLA folks that would beg to differ > on that viewpoint. :)
Yeah, I think declaring entire cycles to be stabilization vs feature focused is faaaaar to coarse & inflexibile. The most likely effect of it would be that people who would otherwise contribute useful features to openstack will simply walk away from the project for that cycle. I think that in fact the time when we need the strongest focus on bug fixing is immediately after sizeable features have merged. I don't think you want to give people the message that stabalization work doesn't take place until the next 6 month cycle - that's far too long to live with unstable code. Currently we have a bit of focus on stabalization at each milestone but to be honest most of that focus is on the last milestone only. I'd like to see us have a much more explicit push for regular stabalization work during the cycle, to really re-inforce the idea that stabilization is an activity that should be taking place continuously. Be really proactive in designating a day of the week (eg "Bug fix wednesdays") and make a concerted effort during that day to have reviewers & developers concentrate exclusively on stabilization related activities. > That said, I entirely agree with you and wish efforts to stabilize would > take precedence over feature work. I find it really contradictory that we have such a strong desire for stabilization and testing of our code, but at the same time so many people argue that the core teams should have nothing at all todo with the stable release branches which a good portion of our users will actually be running. By ignoring stable branches, leaving it upto a small team to handle, I think we giving the wrong message about what our priorities as a team team are. I can't help thinking this filters through to impact the way people think about their work on master. Stabilization is important and should be baked into the DNA of our teams to the extent that identifying bug fixes for stable is just an automatic part of our dev lifecycle. The quantity of patches going into stable isn't so high that it take up significant resources when spread across the entire core team. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev