[openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
robertc at robertcollins.net
Wed Jul 29 21:47:42 UTC 2015
On 30 July 2015 at 09:02, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
> On 7/29/2015 12:45 PM, Sean Dague wrote:
>> I thought Matt said there was a coupling here between stable/kilo and
>> master. That would imply that all of master would need changes as well,
>> right? And block merges until stable is fixed for everything in the
>> grenade job?
> The old side of grenade for master changes is kilo, so when pbr explodes on
> stable/kilo for a version change, it not only blocks that project in
> stable/kilo but also grenade for anything using that project in master with
> a grenade job.
I don't understand. Kilo *tagged revisions* are fine. How is that
message:"ValueError: git history requires a target version of
pbr.version.SemanticVersion(2015.1.2), but target version is
pbr.version.SemanticVersion(2015.1.1)" AND tags:"console" AND
gives only 10 hits in the last 6 days.
So 3 different patches affected (sure, so far). Lets drill in.
which has a kilo patch (https://review.openstack.org/#/c/203236/) - so
the kilo patch will be triggering in the gate and causing this to
break on kilo in grenade. That kilo patch is -2'd already, but
changing it do Depends-On the version bump in kilo will fix 182365
without costing 182365 votes.
https://review.openstack.org/#/c/198904 current rev doesn't depend-on
anything, but there is a stale implicit dependency
https://review.openstack.org/#/c/198730/16 which depends-on
https://review.openstack.org/#/c/205611/ - and is in fact the third
I found https://review.openstack.org/#/c/198730/ which is a master
change but it Depends-On https://review.openstack.org/#/c/205611/
which is a kilo only change [in fact one that is marked DO NOT
> Plus 'just rub some Depends-On' isn't great if your code has been approved
> since you'll lose your votes by having to add that to the commit message.
For master changes sure. But so far I haven't found a single change
that is truely Just Master and problematic. So - so far it is looking
'changes to stable branches have to sequence behind the stable version bump'
which will transitively fix the patches to master that are Depends-On
> I guess you could push up all of the setup.cfg version changes before
> pushing the release tag to narrow the window, but it doesn't help much since
> you can't land those changes until the release tag is pushed, at which point
> you've set the timer for things exploding, so a chicken-and-egg if you're
> not using post-versioning.
I think pushing them up earlier would indeed make it easier for folk.
But its not as good as using post-versioniing :)
So really - I still don't buy 'exploding'. Two patches have themselves
depended-on changes in Kilo, and a third patch is a child of one of
those. Thats not a huge developer productivity sink to deal with.
Robert Collins <rbtcollins at hp.com>
HP Converged Cloud
More information about the OpenStack-dev