Open Stack

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 <thierry at 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