Open Stack

On 04/16/2015 04:27 PM, Mike Dorman wrote:
> 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?

I'm trying a new hook in jeepyb: https://review.openstack.org/#/c/174627/1

This is a PoC, just to see how people reacts about that.

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

I think you summarize very well: we need to change our backport behavior
and win the trust of people deploying Puppet OpenStack from master, so
they can see our stable branches will fit their needs.

> 
> 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
>>
> __________________________________________________________________________
> 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/ea6b1b94/attachment.pgp>