Open Stack

In a tangent in a cross-posted thread, John Dickinson suggested:

> What I heard from ops in the room is that they want (to start) one release a year who's branch isn't deleted after a year. What if that's exactly what we did? I propose that OpenStack only do one release a year instead of two. We still keep N-2 stable releases around. We still do backports to all open stable branches. We still do all the things we're doing now, we just do it once a year instead of twice.

I think that suggestion is worth exploring in a separate thread. I don't
think it's really an alternative solution to the "life after EOL"
discussion, but it could be a complementary solution.

One thing to realize here is that skip-release upgrades are a much
better way to deal with upgrade pain than extending cycles. If you
release every year instead of every 6 months, you get more changes in a
given release, and the upgrade becomes more painful. We should really be
releasing as often as we can, while making sure that upgrades are less
painful and that versions can be skipped.

It's also not a great way to get longer-supported branches. Yes, that
means branches get EOLed after two years rather than one. And yet a lot
of operators would like some branches to be supported for longer than
two years. What's the solution then ? Release every 18 or 24 months ? I
think the proposal for "life after EOL" being discussed in the other
thread is a better way to deal with that.

Doug already replied:

> We have so far only been able to find people to maintain stable
> branches for 12-18 months. Keeping N-2 branches for annual releases
> open would mean extending that support period to 2+ years. So, if
> we're going to do that, we need to address the fact that we haven't
> been able to retain anyone's attention that long up to this point.
> Do you think keeping the branches open longer will be sufficient
> to attract contributors to actually work on them?

And he is right: as the test infrastructure for stable branches break
more often and in more complex ways as time passes, this proposed change
would make their maintenance slightly more costly. We would maintain the
same number of them in parallel though, so it's not a *lot* more costly.

But my main concern was echoed by someone else (but I can't find that
answer anymore, probably lost in the cross-posting between the two lists):

When you don't "release" often enough, the pressure to get your patch
"in" at the end of the cycle increases: missing the boat when the next
one is one year later is just not bearable. Forcing everyone to do
intermediary releases only goes so far: the release that will get a
stable branch is still more important, so that boat is still the one not
to miss.

Now one could argue that the development of OpenStack has slowed down
enough that a release cycle of 9 months or one year (including only one
PTG per cycle) would be a better fit.

Discuss!

-- 
Thierry Carrez (ttx)