Open Stack

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?
>>
>>         -Sean
>>
>
> 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
impacting master?

searching for
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
build_branch:"master"

http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVmFsdWVFcnJvcjogZ2l0IGhpc3RvcnkgcmVxdWlyZXMgYSB0YXJnZXQgdmVyc2lvbiBvZiBwYnIudmVyc2lvbi5TZW1hbnRpY1ZlcnNpb24oMjAxNS4xLjIpLCBidXQgdGFyZ2V0IHZlcnNpb24gaXMgcGJyLnZlcnNpb24uU2VtYW50aWNWZXJzaW9uKDIwMTUuMS4xKVwiIEFORCB0YWdzOlwiY29uc29sZVwiICBBTkQgYnVpbGRfYnJhbmNoOlwibWFzdGVyXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjYwNDgwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MzgyMDU5NzQ0MzZ9

gives only 10 hits in the last 6 days.

Of those:
http://logs.openstack.org/65/182365/11/check/gate-grenade-dsvm-neutron/79aa183/logs/grenade.sh.txt
http://logs.openstack.org/65/182365/11/check/gate-grenade-dsvm-neutron/79aa183/logs/grenade.sh.txt
http://logs.openstack.org/04/198904/6/check/gate-grenade-dsvm/8b6f7e5/logs/grenade.sh.txt
http://logs.openstack.org/04/198904/6/check/gate-grenade-dsvm/8b6f7e5/logs/grenade.sh.txt
http://logs.openstack.org/04/198904/6/check/gate-grenade-dsvm-partial-ncpu/afddd41/logs/grenade.sh.txt
http://logs.openstack.org/04/198904/6/check/gate-grenade-dsvm-partial-ncpu/afddd41/logs/grenade.sh.txt
http://logs.openstack.org/30/198730/16/check/gate-grenade-dsvm-partial-ncpu/2d10980/logs/grenade.sh.txt
http://logs.openstack.org/30/198730/16/check/gate-grenade-dsvm-partial-ncpu/2d10980/logs/grenade.sh.txt
http://logs.openstack.org/30/198730/16/check/gate-grenade-dsvm/69a5c08/logs/grenade.sh.txt
http://logs.openstack.org/30/198730/16/check/gate-grenade-dsvm/69a5c08/logs/grenade.sh.txt

So 3 different patches affected (sure, so far). Lets drill in.
https://review.openstack.org/#/c/182365/ depends-on
https://review.openstack.org/#/q/I9134fbf5ce72c32cca91de90001c09e00b4e19e8,n,z
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
patch here.

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
MERGE]'.

> 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
like:
'changes to stable branches have to sequence behind the stable version bump'
which will transitively fix the patches to master that are Depends-On
stable patches.

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

-Rob


-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud