Open Stack

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

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.


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

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

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