Open Stack

On 17/08/15 15:29, James Slagle wrote:
>> >
>> >I'd like propose we take a somewhat modified "release branch" approach,
>> >which combines many of the advantages of the stable-branch model, but
>> >allows for a somewhat more liberal approach to backports, where most things
>> >are considered valid backports provided they work with the currently
>> >released OpenStack services (e.g right now, a t-h-t release/kilo branch
>> >would have to maintain compatibility with a kilo Heat in the undercloud)
> I like the idea, it seems reasonable to me.
>
> I do think we should clarify if the rule is:
>
> We*can*  backport anything to release/kilo that doesn't break
> compatibility with kilo Heat.
>
> Or:
>
> We*must*  backport anything to release/kilo that doesn't break
> compatibility with kilo Heat.

I think of it like this: there are theoretically 4 potential models for 
how to combine TripleO and OpenStack:

1) trunk TripleO deploys trunk OpenStack
2) trunk TripleO deploys stable OpenStack
3) stable TripleO deploys trunk OpenStack
4) stable TripleO deploys stable OpenStack

(You could double the size of this list by assuming a user was willing 
to use a different version of OpenStack in the undercloud than they're 
installing in the overcloud. However, I believe we are working on the 
assumption that they are not.)

To date, TripleO has supported only (1). This is a proposal to support 
(2). I'll hazard a guess that nobody cares about (3) right now. This is 
explicitly *not* a proposal to support (4) - i.e. it is not a stable/ 
branch (we'll continue to leave that job to downstream distros).

So we should think of this as a development branch that allows users to 
consume the latest TripleO features without breaking compatibility with 
the stable OpenStack packages. So, in RFC2119 terms, I believe the 
correct policy is we SHOULD backport anything to release/kilo (or 
whatever we call it) that doesn't break compatibility with kilo OpenStack.

cheers,
Zane.