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 <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.
++ 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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
