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" <emil...@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 <emil...@redhat.com >> <mailto:emil...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
