Open Stack

On Thu, Apr 16, 2015 at 2:10 PM, Richard Raseley <richard at raseley.com>
wrote:

> I am certainly sympathetic to your situation - having the world change
> beneath your feet is never a good place to be. =]
>
> It does seem, however, that there is a disconnect between your
> expectations (as I understand them) of what the 'master' branch represents,
> and what it has traditionally represented - the 'bleeding edge'
>
> Master is volatile - it is expected to be volatile. As the code progresses
> between releases it is expected that things can (and will) break.
>
> The solution, in my mind, is not to redefine what it means to be master,
> but rather to be more aggressive about back-porting changes to stable
> branches.
>

I agree that in theory, it should work like you suggest.  However, as they
say: “In theory, theory and practice are the same. In practice, they are
not.”  In practice, we're not as good at back porting things as everyone
would like.  I'll be as happy as anyone else to see this continue to
improve, but it's a given that it'll never be perfect.   In practice, if
you wanted to upgrade to Juno, we needed to be on master, because even in
January it wasn't ready for the sort of configurations we were running, and
we're not doing anything overly weird.

Additionally, as Matt said, those of us that are upgrading production
environments are the ones contributing back fixes that have to land in
master first, and then we have to wait for an additional back port.  We've
several times found bugs that break production deployments and had to carry
local patches, but we try to contribute everything back as quickly as
possible.  We'll continue to do this regardless, but we certainly have less
incentive to do it quickly if we're going to have to carry it locally for
the length of time a back port takes.

I am very much in favor of discussions that include your proposed solution
> above (i.e. 'current-1' support), as long as it is identified as a
> transitional step; I do pretty strongly believe that the right long-term
> model is to treat master as the 'bleeding edge' and to only pin yourself to
> stable releases.
>

We're not following master blindly.  We import most modules once a week,
run them through CI before merging them and QA them before deploying.
Doing that is *dramatically* easier than trying to update to a new,
massively different puppet module twice a year.  If there is no overlapping
compatibility between <current release> and <previous release> then
upgrading requires making massive changes to infrastructure while making
massive changes to the automation that drives it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150416/d61a35c4/attachment.html>