On Wed, Aug 13, 2014 at 11:42:52AM +0100, Daniel P. Berrange wrote: > 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.
Does such an argument actually exist? My experience has been that stable-maint folks are very accepting of help, and that it's relatively easy for core reviewers with an interest in stable branch maintenance to offer their services and become stable-maint core: https://wiki.openstack.org/wiki/StableBranch#Joining_the_Team > 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. Who is ignoring stable branches? This sounds like a project specific failing to me, as all experienced core reviewers should consider offering their services to help with stable-maint activity. I don't personally see any reason why the *entire* project core team has to do this, but a subset of them should feel compelled to participate in the stable-maint process, if they have sufficient time, interest and historical context, it's not "some other team" IMO. > 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. +1 Also, contributors should be more actively encouraged to propose their bugfixes as backports to stable branches themselves, instead of relying on $someone_else to do it. Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
