On Thu, Sep 22, 2016 at 04:25:00PM +1000, Tony Breeds wrote: > On Wed, Sep 21, 2016 at 02:05:51PM -0400, Sean Dague wrote: > > > Well, the risk profile of what has to be changed for stable/liberty > > (given that all the actual code is buried in libraries which have tons > > of other changes). Special cherry-picked library versions would be > > needed to fix this without openning up a ton of risk for breaking > > stable/liberty badly. > > > > That is the bit of work that no one seems to really have picked up. > > So to clearly describe the work you touch on here: > > We have: > * global-requirements.txt: > origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0 > * upper-constraints.txt > origin/stable/liberty : oslo.concurrency===2.6.1 > * compatible oslo.concurrency releases: > 2.3.0, 2.4.0, 2.5.0, 2.6.0 and 2.6.1(patched) > > So to be sure that all liberty consumers have a reasonably simple update we'd > need to create: > 2.3.1, 2.4.1 and 2.5.1 > releases of oslo.concurrency > > To achieve this we'd need to create a 3 short lived feature branches in > oslo.concurrency and (I'm guessing) some CI changes so we can merge/release > these versions. > > We'd also need to update global-requirements.txt to: > oslo.concurrency>=2.3.1,!=2.4.0,!=2.5.0,!=2.6.0 > > This update would be propagated to all projects: > > Package : oslo-concurrency [oslo-concurrency>=2.3.0] (used by 30 > projects) > Re-Release : 5 projects > Included in : 17 projects > Also affects : 8 projects > > (The expanded list is at http://paste.openstack.org/show/582499/) > > I haven't looked into the state of the libraries that need a re-release, but > my > guess is that they'll have knock on effects if we're going to do this > properly. > > There's a reason we call this kind of thing a tangled web of onions. > > I suppose the most flexible solution would be to: > > 1. Release the .1 versions > 2. Leave global-requirements.txt > 2. Add the patch to nova to with with/without the fix > 3. Write appropriate words in the OSSN/OSSA > > That gives deployers plenty of packages they can work with and public > backports > of the fixes. Yes g-r would be sub-optimal but the only thing that needs the > fix will function with any of the versions listed.
Thanks for the succint analysis, Tony, that gives a clear view of state of affairs if we had to go with three short-lived .1 releases. Probably this thread needs to be referred to in the commit message. > .... Time passes .... > > So I checked and the cherry-picks to 2.[345].0 are trivial so I think > I just talked myself around to taking the nova fix now we can decide > if we do all the .1 releases later So, given your above comment, we seem to be going with the "option (1)" as mentioned in the original post[x] -- i.e. merge the Nova backport. Thanks for the review (and the test with 2.6.0) [x] http://lists.openstack.org/pipermail/openstack-dev/2016-September/104091.html -- /kashyap __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
