Open Stack

I feel somewhat responsible for this whole thing, since I landed the first 
review that kicked off all this.  We had gone to a kilo oslo-messaging for 
RMQ improvements, which was what spurred me to patch in order to get rid 
of the deprecation warnings.  I should have actually validated it against 
Juno, known it would break, and called that out.  Sorry about that.  (On 
the other hand, thanks to Gael for hitting up all the other modules that I 
did not do.)

But, I have to say that I’m sympathetic with Matt on this.  We also more 
or less track the master branches, and have the same challenge.

Emilien’s idea below for a bot creating the backport cherry pick is 
intriguing.  Tbh, from a contributor’s perspective, the main reason I 
would not create the cherry pick review is 1) lack of time, and, 2) I’m 
tracking master so I (selfishly) don’t necessarily care about the stable 
branch.  If we had a bot that would automate some of this process, that 
would reduce the resistance somewhat.  But I have no idea what the 
effort/feasibility is of setting up such a thing.  Is there a way in 
Gerrit to make tags more visible when viewing a review?  Like checkboxes 
or something, rather than just having to know the tag and typing it in?

For me, personally, I would be more open to tracking stable branches, too, 
if the backports were better/faster.  Once I was on a stable branch, I 
would be more motivated to do the cherry picks/backports as well.  So 
maybe somewhat of a chicken-and-egg thing.

In any case, definitely a challenge that we should come to some decision 
on.  Then at least there’ll be consistent behavior, one way or another, 
going forward.

Mike

 




On 4/16/15, 12:42 PM, "Emilien Macchi" <emilien at redhat.com> wrote:

>
>
>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
>