Open Stack

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. 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 :|