Open Stack

On 25 February 2015 at 00:05, Thierry Carrez <thierry at openstack.org> wrote:
> Daniel P. Berrange wrote:
>> [...]

>
> I think you're judging the cycle from the perspective of developers
> only.

You said that in the other thread, and I think its false. There is a
very good case to be made that the release cycle is directly
responsible for:
 - increased feature latency [when users get new shiny] - already
explained here.
 - decreased stability due to feature crush
 - decreased quality for the same reason - we don't put things in and
bake them before exposing, we get them in and since there is a long
gap before they can be consumed they're generally just enabled
immediately. Keystone's steps to address that are excellent, but made
harder by the gap between releases: there is social pressure to make
things graduate to support within each release.

>  6 months was not an arbitrary decision. Translations and
> documentation teams basically need a month of feature/string freeze in
> order to complete their work. Since we can't reasonably freeze one month
> every 2 months, we picked 6 months.

Do they need a month because 6 months worth of changes have been
aggregated? E.g. if they have 2 months of changes to deal with, do
they need 1.5 weeks?

Perhaps we could branch the code release in advance of docs and
translations, and announce the release when those artifacts are ready?

> It's also worth noting that we were on a 3-month cycle at the start of
> OpenStack. That was dropped after a cataclysmic release that managed the
> feat of (a) not having anything significant done, and (b) have out of
> date documentation and translations.

Oh! https://wiki.openstack.org/w/index.php?title=Obsolete:3MonthReleaseCycle&direction=prev&oldid=14016
appears to be the page about that, but my google-fu isn't turning up a
post-mortem of the C release which prompted the change. Perhaps some
old-hand like you can fill us in on the details :).

> Stable branches may have the luxury of skipping releases and designate a
> "stable" one from time to time (I reject the Linux comparison because
> the kernel is at a very different moment in software lifecycle). The
> trick being, making one release "special" is sure to recreate the peak
> issues you're trying to solve.
>
> I'm actually more concerned about the teams that don't have the luxury
> of skipping a release (like the vulnerability management team). Docs and
> translations, as mentioned above, will also have a hard time producing
> quality docs and translations every 2 months with a very short freeze
> period.

I agree that the vulnerability team will be rather more impacted by
this than regular project teams - I made a nod to that in the other
thread. More thought needed still :).


> I may appear defensive on my answers, but it's not my goal to defend the
> current system: it's just that most of those proposals generally ignore
> the diversity of the needs of the teams that make OpenStack possible, to
> focus on a particular set of contributors' woes. I'm trying to bring
> that wider perspective in -- the current system is a trade-off and the
> result of years of evolution, not an arbitrary historic choice that we
> can just change at will.

I agree that its not arbitrary and that changing it requires some
appropriate wide-spread consultation; OTOH the benefits of rolling and
higher frequency releases are really substantial: but we have to
backup the change with the appropriate engineering (such as reducing
our frictions that cause teams practicing CD to be weeks behind tip)
to make it feasible. My greatest concern about the proposals happening
now is that we may bite off more than we can chew. OTGH the reality is
that all the negative things multiply out, so we probably need to just
start somewhere and /do/ to give us the space to fix other things.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud