[openstack-dev] [all] The future of the integrated release
jaypipes at gmail.com
Thu Aug 14 23:20:11 UTC 2014
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'
>>> 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,
More information about the OpenStack-dev