Open Stack

On 04/16/2015 02:15 PM, Clayton O'Neill wrote:
> On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi <emilien at redhat.com
> <mailto:emilien at redhat.com>> wrote:
> 
>     We do our best now to backport what is backportable to stable/juno.
> 
> 
> This certainly has gotten much better, but I don't think it's 100% there
> yet either.  It's just a ton of work and we probably need better tooling
> around this to expect it to be as good as it should be.
>  
> 
>     FWIW, even without rabbit/kombu topic, master won't work on Juno, there
>     is plenty of things that are brought in Kilo.
> 
> 
> That may be the case in some areas, but we're using it without issues
> (until now) on Ubuntu with the features we need.
>  
> 
>     My opinion is we should follow other projects that use stable branches
>     with doing deprecation for one (or more?) release (currently our master)
>     and then drop the deprecations after some time.
> 
>     So I would propose this policy:
>     * for new features, patch master with backward compatibility
> 
> 
> Agreed, I think some of these might also be candidates for back port if
> they're new "module features".  For example a new cinder backend that
> existed in the previous release might get back ported if they're just
> adding a new class.
>  

A solution could be to add a tag in commits that can be backported?
Something like:

backport-juno
backport-icehouse

or just:
backport-icehouse

And the patch once merged would create the backport auto-magically with
a bot ?

We would have to add a rule in our policy, to ensure a patch has the tag
if needed (core-reviewers will have to take care to see if the tag
deserves to be here or not).
This is a proposal, it could be wrong at all.

>     * backports relevant patches from master to stable branches (mainly
>     bugs)
> 
> Agreed.
>  
> 
>     * in the case of rabbit or any update in OpenStack upstream, update
>     master without backward compatibility, except if we accept to have a lot
>     of if/else in our code, and a lot of backwards to support; I'm not in
>     favor of that.
> 
> 
> I think I agree here also.  However, I'd like to see us avoid making
> breaking changes solely to avoid deprecation warnings until x amount of
> time after a release comes out.  If we're able to support some level of
> backwards compatibility, then it also makes upgrading between releases a
> lot easier.  Upgrading all of your packages, db schemas, etc is a lot
> less scary and easier to test than upgrading all that + every OpenStack
> puppet module you use at the same time.

Well, we also rely on OpenStack upstream (oslo, etc), that use to change
configuration parameters. But I agree with you, we should more take care
of this kind of changes.

> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Emilien Macchi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150416/534773fa/attachment.pgp>