Flavio Percoco <fla...@redhat.com> wrote on 01/21/2016 09:13:02 AM:
> From: Flavio Percoco <fla...@redhat.com>
> To: "Daniel P. Berrange" <berra...@redhat.com>
> Cc: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev@lists.openstack.org>
> Date: 01/21/2016 01:47 PM
> Subject: Re: [openstack-dev] [all][tc] Stabilization cycles:
> Elaborating on the idea to move it forward
>
> On 21/01/16 11:22 +0000, Daniel P. Berrange wrote:
> >On Wed, Jan 20, 2016 at 01:23:02PM -0430, Flavio Percoco wrote:
> >> Greetings,
> >>
> >> At the Tokyo summit, we discussed OpenStack's development themes in a
> >> cross-project session. In this session a group of folks started
> discussing what
> >> topics the overall community could focus on as a shared effort. One
of the
> >> things that was raised during this session is the need of having
cycles to
> >> stabilize projects. This was brought up by Robert Collins again in
> a meeting[0]
> >> the TC had right after the summit and no much has been done ever
since.
> >>
> >> Now, "stabilization Cycles" are easy to dream about but really hardto
do and
> >> enforce. Nonetheless, they are still worth a try or, at the very
least, a
> >> thought. I'll try to go through some of the issues and benefits a
> stabilization
> >> cycle could bring but bear in mind that the lists below are not
> exhaustive. In
> >> fact, I'd love for other folks to chime in and help building a case
> in favor or
> >> against this.
> >>
> >> Negative(?) effects
> >> ===================
> >>
> >> - Project won't get new features for a period of time Economic impact
on
> >> developers(?)
> >> - It was mentioned that some folks receive bonuses for landed
features
> >> - Economic impact on companies/market because no new features were
added (?)
> >> - (?)
> >
> >It will push more development into non-upstream vendor private
> >branches.
> >
> >>
> >> Positive effects
> >> ================
> >>
> >> - Focus on bug fixing
> >> - Reduce review backlog
> >> - Refactor *existing* code/features with cleanups
> >> - Focus on multi-cycle features (if any) and complete those
> >> - (?)
> >
> >I don't think the idea of stabalization cycles would really have
> >such a positive effect, certainly not while our release cycle is
> >6 months in length.
> >
> >If you say the next cycle is primarily stabalization, then what
> >you are in effect saying is that people have to wait 12 months
> >for their desired new feature. In the fast moving world of
> >cloud, I don't think that is a very credible approach. Even
> >with our current workflow, where we selectively approve features
> >for cycles, we have this impact of forcing people to wait 12
> >months, or more, for their features.
>
> ++
>
> This is one of the main concerns and perhaps the reason why I don't
think it
> should be all-or-nothing. It should be perfectly fine for teams to have
> stabilization milestones, FWIW.
>
> >In the non-stabalization cycle, we're not going to be able to
> >merge a larger number of features than we already do today.
> >So in effect we'll have 2 cycles worth of features being
> >proposed for 1 cycle. When we inevitably reject moany of
> >those features they'll have to wait for the next non-stabalization
> >cycle, which means 18-24 months delay.
> >
> >Of course in reality this kind of delay won't happen. What will
> >instead happen is that various vendors will get pressure from
> >their customers/partners and their local branches of openstack
> >packages will fork & diverge even further from upstream than
> >they already do today.
> >
> >So while upstream branch will be "stabalized", most users will
> >probably get a *less* stable release because they'll be using
> >a branch from vendors with a tonne of non-upstream stuff added.
> >
>
> I would expect these vendors to (slowly?) push their changes
upstream.It'd take
> time but it should certainly happen.
>
> >In addition having a stablization cycle will give the impression
> >that the following cycle is a non-stable one and likely cause
> >more distruption by pushing lots of features in at one time.
> >Instead of having a master branch which has an approximately
> >constant level of stabalization, you'll create a situation
> >where it fluctuates significantly, which is clearly worse for
> >people doing continuous deployment.
> >
> >I think it is important to have the mindset that master should
> >*always* be considered stable - we already have this in general
> >and it is one of the success points of openstack's development
> >model IMHO. The idea of stabalization cycles is a step backwards
>
> Perhaps, it is being presented the wrong way. I guess the main point
here is how
> ca we communicate that we'd like to take some time to clean-up the mess
we have
> in some projects. How can projects ask their team to put more efforts on
> tackling technical debt rather than pushing the new sexy thing?
>
> I could consider Mitaka as a stabilization cycle for Glance (except for
the
> upload path refactor spec). The team has spent quite some time on
working out a
> way to improve that workflow. Few other specs have been implemented but
nothing
> major, TBH (talking about Glance here, not the other components).
>
> What I mean is, that I don't consider a stabilization cycle a full
heads-down on
> bug fixing cyle but rather a cycle where no major features are approved.
What
> unfortunatelly happens when these kind of cycles are announced or
planned is
> that contributions vanish and they are routed to places where new
features land.
> That should perhaps be an indicator of how good/bad these cycles are.
*shurgs*
>
> >I still believe that if you want to improve stabality of the
> >codebase, we'd be better off moving to a shorter development
> >cycle. Even the 6 month cycle we have today is quite "lumpy"
> >in terms of what kind of work happens from month to month. If
> >we moved to a 2 month cycle, I think it would relieve pressure
> >to push in features quickly before freeze, because people would
> >know they'd have another opportunity very soon, instead of having
> >to wait 6+ months. I've previously suggested that here:
> >
> >
http://lists.openstack.org/pipermail/openstack-dev/2015-February/057614.html
> >
>
> Whether we move to shorter cycles or not, I still think there's a way we
can do
> this now. Again, I don't believe these cycles should be
all-or-nothingand teams
> should feel free to dedicate as much time to this as they want (and
> some do already).
>
> Flavio
>
> >Regards,
> >Daniel
I try to handle in one post the different aspects which came up so far:
wrt dedicated stabilization cycles|milestones:
Piled up (=older) bugs are harder to solve than fresh ones.
I've seen next to no bug report in Nova which has all the
necessary data to do a proper analysis. There are usually
1-3 requests to the bug reporter necessary to get enough data.
This makes me believe that stabilization should be a continuous
effort.
wrt cycle length:
To get things merged in a specific cycle is indeed a big thing
for my employer (at least the parts I directly interact with).
A lot of effort goes into coordinating internal plans with the
OpenStack cycles. Decreasing the length of a cycle (2-4 months)
could make things a bit more relaxed.
wrt "just fixing bugs":
User experience is not only based on shiny features. I assume
that a fixed bug isn't a big differentiator for a company, which
makes that an unattractive task for them. The only possible
motivator I can think of is prestige. A bullet point on a company
slide that says "we solved 25% of the open bugs" could be a thing.
Having those "metrics" in the spotlight is maybe a thing?
Regards, Markus Zoeller (markus_z)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
