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" <[email protected]> wrote: > >> >> >> On 04/16/2015 02:15 PM, Clayton O'Neill wrote: >>> On Thu, Apr 16, 2015 at 10:50 AM, Emilien Macchi <[email protected] >>> <mailto:[email protected]>> 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: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> -- >> Emilien Macchi >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
