Open Stack

On 08/13/2014 06:42 AM, 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.

++ I actually proposed just that at the mid-cycle in a ML thread a 
couple weeks ago -- though for the life of me I can't remember the exact 
topic of the ML thread so I can't link to it :)

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

Well, as one of the folks who said that the mindset of folks doing 
stable branch maintenance/approvals is different from that of folks 
working on master...

I don't disagree that stable fixes/backports are important. I just am 
being realistic in saying that, for me personally, stable branches are 
not interesting to me (I don't actually equate stabilization efforts 
with the stable branches) and therefore I don't want to commit to doing 
stable branch reviews (nor do I want to be asked to do those reviews). 
Call it selfish; I just call it being honest about where my priorities 
and desires lie.

All the best,
-jay