Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
Agreed, after 2015.1.2 version bumps are merged, I'll propose version= line removals on stable branches so this situation doesn't happen again. Err, no. Post-versioning means all projects use semantic rather than date-based version numbers, which happens starting with *liberty*. Remaining kilo and juno stable releases will still need to use pre-versioning. Actually, post/pre doesn't make a difference on stable branches. I tried locally on keystone stable/kilo and generated versions stay the same. * current pre-version setup i.e. version = 2015.1.2 in setup.cfg ** commit 070b51603879f0f70f85f72e9e82126d1bb398ba Bump stable/kilo next version to 2015.1.2 2015.1.2.dev1 ** review 205130 rebased on top of 070b516 Bump... 2015.1.2.dev2 * post-version i.e. version = line removed from setup.cfg on top of 070b516 Bump... commit fb9582acc739d7719da0f1cc5f29b9e24097e025 Author: Alan Pevec alan.pe...@redhat.com Date: Thu Jul 30 12:07:27 2015 +0200 Switch to post-versioning Change-Id: Ie4758058672bdeff86147f796d53f602a65228f1 diff --git a/setup.cfg b/setup.cfg index e8d84e3..da0edb9 100644 --- a/setup.cfg +++ b/setup.cfg @@ -1,6 +1,5 @@ [metadata] name = keystone -version = 2015.1.2 summary = OpenStack Identity description-file = README.rst 2015.1.2.dev2 ** review 205130 rebased on top of Switch to post-versioning 2015.1.2.dev3 And when I tag that commit locally: $ git tag 2015.1.2 $ python ./setup.py --version 2015.1.2 Then one backport on top of that: 2015.1.3.dev1 So all is good and safe to remove version = lines from setup.cfg on stable branches. Cheers, Alan __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
Alan Pevec wrote: I think pushing them up earlier would indeed make it easier for folk. Indeed, but it's too late now. But its not as good as using post-versioniing :) Agreed, after 2015.1.2 version bumps are merged, I'll propose version= line removals on stable branches so this situation doesn't happen again. Err, no. Post-versioning means all projects use semantic rather than date-based version numbers, which happens starting with *liberty*. Remaining kilo and juno stable releases will still need to use pre-versioning. The way we did it in the past was to push the setup.cfg version=2015.1.2 bump BEFORE we tag, then once that is merged, tag the previous commit in history as 2015.1.1. That way you avoid the lockstep (and ensure no intermediary badly-versioned tarball can be produced). Any reason why that wouldn't work anymore ? -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
The way we did it in the past was to push the setup.cfg version=2015.1.2 bump BEFORE we tag, then once that is merged, tag the previous commit in history as 2015.1.1. That way you avoid the lockstep (and ensure no intermediary badly-versioned tarball can be produced). Any reason why that wouldn't work anymore ? It should've worked but we didn't update the current stable release procedure which I was following. We have documented pushing tags in step https://wiki.openstack.org/wiki/StableBranchRelease#Tag and pushing version bumps only later, after Close bugs and Upload The Release: https://wiki.openstack.org/wiki/StableBranchRelease#Rinse.2C_Repeat Let's update this procedure since we still have few Kilo and Juno point releases to be done. Cheers, Alan __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 30 July 2015 at 01:39, Sean Dague s...@dague.net wrote: So, after every release a giant amount of patches all have to land lock step or everything is broken? No, its not that bad. The *tagged* commit is fine forever. The *first* commit in each branch has to be the identification of the new version in that branch. So there is no race, and as long as you put up the new patch straight away (which is AIUI part of the release manager process), everyone else can Depends-On: I that patch, and things will be sane. That said, yes, removing the version= line as unnecessary should make things a lot simpler. The change in pbr 0.11 was to fix a bug: the bug was that when there is a version in setup.cfg, and a tag thats equal or higher, there are no versions to pick from by the backwardly defined rules for setup.cfg: the old code happily generated versions *IN THE PAST*. The new code had a choice: - error - decide it knew better than the owner of setup.cfg and start incrementing versions above it At the time we chose to error, based on the reasoning that: - there was already a process to put new versions in setup.cfg at release time - the gate wouldn't be broken at all because its self checking - overriding pre-versioning seemed against the entire *intent* of pre-versioning. If a bunch of folk are going to say 'hey, we want a knob to make this take the 'decide pbr knows better' path, I'm entirely willing to support just changing the decision from 'error' to 'decide it knows better'. It was arbitrary but conservative. However - see above - I think the impact of the release is being overstated. If I have that wrong, please help me understand whats happened here. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 7/29/2015 12:45 PM, Sean Dague wrote: On 07/29/2015 01:21 PM, Robert Collins wrote: On 30 July 2015 at 01:39, Sean Dague s...@dague.net wrote: So, after every release a giant amount of patches all have to land lock step or everything is broken? No, its not that bad. The *tagged* commit is fine forever. The *first* commit in each branch has to be the identification of the new version in that branch. So there is no race, and as long as you put up the new patch straight away (which is AIUI part of the release manager process), everyone else can Depends-On: I that patch, and things will be sane. That said, yes, removing the version= line as unnecessary should make things a lot simpler. The change in pbr 0.11 was to fix a bug: the bug was that when there is a version in setup.cfg, and a tag thats equal or higher, there are no versions to pick from by the backwardly defined rules for setup.cfg: the old code happily generated versions *IN THE PAST*. The new code had a choice: - error - decide it knew better than the owner of setup.cfg and start incrementing versions above it At the time we chose to error, based on the reasoning that: - there was already a process to put new versions in setup.cfg at release time - the gate wouldn't be broken at all because its self checking - overriding pre-versioning seemed against the entire *intent* of pre-versioning. If a bunch of folk are going to say 'hey, we want a knob to make this take the 'decide pbr knows better' path, I'm entirely willing to support just changing the decision from 'error' to 'decide it knows better'. It was arbitrary but conservative. However - see above - I think the impact of the release is being overstated. If I have that wrong, please help me understand whats happened here. 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. 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. 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. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 30 July 2015 at 09:02, Matt Riedemann mrie...@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 rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 30 July 2015 at 05:45, Sean Dague s...@dague.net wrote: On 07/29/2015 01:21 PM, Robert Collins wrote: However - see above - I think the impact of the release is being overstated. If I have that wrong, please help me understand whats happened here. 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? Indeed, that would be a terrible place to be in. But see my analysis - there is no evidence that we're in that place. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
I think pushing them up earlier would indeed make it easier for folk. Indeed, but it's too late now. But its not as good as using post-versioniing :) Agreed, after 2015.1.2 version bumps are merged, I'll propose version= line removals on stable branches so this situation doesn't happen again. Cheers, Alan __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 07/29/2015 01:21 PM, Robert Collins wrote: On 30 July 2015 at 01:39, Sean Dague s...@dague.net wrote: So, after every release a giant amount of patches all have to land lock step or everything is broken? No, its not that bad. The *tagged* commit is fine forever. The *first* commit in each branch has to be the identification of the new version in that branch. So there is no race, and as long as you put up the new patch straight away (which is AIUI part of the release manager process), everyone else can Depends-On: I that patch, and things will be sane. That said, yes, removing the version= line as unnecessary should make things a lot simpler. The change in pbr 0.11 was to fix a bug: the bug was that when there is a version in setup.cfg, and a tag thats equal or higher, there are no versions to pick from by the backwardly defined rules for setup.cfg: the old code happily generated versions *IN THE PAST*. The new code had a choice: - error - decide it knew better than the owner of setup.cfg and start incrementing versions above it At the time we chose to error, based on the reasoning that: - there was already a process to put new versions in setup.cfg at release time - the gate wouldn't be broken at all because its self checking - overriding pre-versioning seemed against the entire *intent* of pre-versioning. If a bunch of folk are going to say 'hey, we want a knob to make this take the 'decide pbr knows better' path, I'm entirely willing to support just changing the decision from 'error' to 'decide it knows better'. It was arbitrary but conservative. However - see above - I think the impact of the release is being overstated. If I have that wrong, please help me understand whats happened here. 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 -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 07/29/2015 09:29 AM, Matt Riedemann wrote: On 7/29/2015 8:17 AM, Matt Riedemann wrote: stable/kilo and grenade (master) jobs are going to be blocked for some projects until the kilo 2015.1.2 version changes are merged: https://review.openstack.org/#/q/I180de9d4f1f4ae385682ce40a3a695eb3acc4c43,n,z So avoid rechecks for grenade failures until these are merged (at least nova and ironic at this point). The error is like this during devstack setup: ValueError: git history requires a target version of pbr.version.SemanticVersion(2015.1.2), but target version is pbr.version.SemanticVersion(2015.1.1) http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVmFsdWVFcnJvcjogZ2l0IGhpc3RvcnkgcmVxdWlyZXMgYSB0YXJnZXQgdmVyc2lvbiBvZiBwYnIudmVyc2lvbi5TZW1hbnRpY1ZlcnNpb24oMjAxNS4xLjIpLCBidXQgdGFyZ2V0IHZlcnNpb24gaXMgcGJyLnZlcnNpb24uU2VtYW50aWNWZXJzaW9uKDIwMTUuMS4xKVwiIEFORCB0YWdzOlwiY29uc29sZVwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDM4MTc1NTc3NzIwfQ== Trove is blocked on stable/kilo due to this bug: https://bugs.launchpad.net/trove/+bug/1479358 So, after every release a giant amount of patches all have to land lock step or everything is broken? That seems pretty fragile. Can we revisit whatever decision caused this issue? -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
Excerpts from Sean Dague's message of 2015-07-29 09:54:08 -0400: On 07/29/2015 09:49 AM, Jeremy Stanley wrote: On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote: On 07/29/2015 09:29 AM, Matt Riedemann wrote: On 7/29/2015 8:17 AM, Matt Riedemann wrote: [...] ValueError: git history requires a target version of pbr.version.SemanticVersion(2015.1.2), but target version is pbr.version.SemanticVersion(2015.1.1) [...] So, after every release a giant amount of patches all have to land lock step or everything is broken? That seems pretty fragile. Can we revisit whatever decision caused this issue? This came with the semver implementation in PBR 0.11, specifically the idea that if your most recent tag is higher than the version you claim to be working toward in setup.cfg then something is terribly wrong and PBR should throw its hands up in the air until you fix your config. Useful in theory, but racy in practice (especially when you have one team of people pushing tags and a different team approving updates to the repo's setup.cfg file). A suitable compromise might be to add a knob to PBR (probably via a directive in setup.cfg) to emit a warning and fall back on version guessing as if the version entry were not present at all. Right, because otherwise we need to account for 1 to 2 days of gate blockage after every stable release, which seems broken by design. Another solution is to move all projects to post-versioning and stop setting a version in setup.cfg. That would mean having all projects following the release:cycle-with-intermediary model, and I intend to propose making that change during mitaka. Doug __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 2015-07-29 10:32:09 -0400 (-0400), Doug Hellmann wrote: Another solution is to move all projects to post-versioning and stop setting a version in setup.cfg. That would mean having all projects following the release:cycle-with-intermediary model, and I intend to propose making that change during mitaka. I fully support this. Getting away from needing to update versions in setup.cfg at all will be great. -- Jeremy Stanley __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 7/29/2015 9:32 AM, Doug Hellmann wrote: Excerpts from Sean Dague's message of 2015-07-29 09:54:08 -0400: On 07/29/2015 09:49 AM, Jeremy Stanley wrote: On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote: On 07/29/2015 09:29 AM, Matt Riedemann wrote: On 7/29/2015 8:17 AM, Matt Riedemann wrote: [...] ValueError: git history requires a target version of pbr.version.SemanticVersion(2015.1.2), but target version is pbr.version.SemanticVersion(2015.1.1) [...] So, after every release a giant amount of patches all have to land lock step or everything is broken? That seems pretty fragile. Can we revisit whatever decision caused this issue? This came with the semver implementation in PBR 0.11, specifically the idea that if your most recent tag is higher than the version you claim to be working toward in setup.cfg then something is terribly wrong and PBR should throw its hands up in the air until you fix your config. Useful in theory, but racy in practice (especially when you have one team of people pushing tags and a different team approving updates to the repo's setup.cfg file). A suitable compromise might be to add a knob to PBR (probably via a directive in setup.cfg) to emit a warning and fall back on version guessing as if the version entry were not present at all. Right, because otherwise we need to account for 1 to 2 days of gate blockage after every stable release, which seems broken by design. Another solution is to move all projects to post-versioning and stop setting a version in setup.cfg. That would mean having all projects following the release:cycle-with-intermediary model, and I intend to propose making that change during mitaka. Doug __ 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 +1 to post-versioning. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote: On 07/29/2015 09:29 AM, Matt Riedemann wrote: On 7/29/2015 8:17 AM, Matt Riedemann wrote: [...] ValueError: git history requires a target version of pbr.version.SemanticVersion(2015.1.2), but target version is pbr.version.SemanticVersion(2015.1.1) [...] So, after every release a giant amount of patches all have to land lock step or everything is broken? That seems pretty fragile. Can we revisit whatever decision caused this issue? This came with the semver implementation in PBR 0.11, specifically the idea that if your most recent tag is higher than the version you claim to be working toward in setup.cfg then something is terribly wrong and PBR should throw its hands up in the air until you fix your config. Useful in theory, but racy in practice (especially when you have one team of people pushing tags and a different team approving updates to the repo's setup.cfg file). A suitable compromise might be to add a knob to PBR (probably via a directive in setup.cfg) to emit a warning and fall back on version guessing as if the version entry were not present at all. -- Jeremy Stanley __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 7/29/2015 8:39 AM, Sean Dague wrote: On 07/29/2015 09:29 AM, Matt Riedemann wrote: On 7/29/2015 8:17 AM, Matt Riedemann wrote: stable/kilo and grenade (master) jobs are going to be blocked for some projects until the kilo 2015.1.2 version changes are merged: https://review.openstack.org/#/q/I180de9d4f1f4ae385682ce40a3a695eb3acc4c43,n,z So avoid rechecks for grenade failures until these are merged (at least nova and ironic at this point). The error is like this during devstack setup: ValueError: git history requires a target version of pbr.version.SemanticVersion(2015.1.2), but target version is pbr.version.SemanticVersion(2015.1.1) http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVmFsdWVFcnJvcjogZ2l0IGhpc3RvcnkgcmVxdWlyZXMgYSB0YXJnZXQgdmVyc2lvbiBvZiBwYnIudmVyc2lvbi5TZW1hbnRpY1ZlcnNpb24oMjAxNS4xLjIpLCBidXQgdGFyZ2V0IHZlcnNpb24gaXMgcGJyLnZlcnNpb24uU2VtYW50aWNWZXJzaW9uKDIwMTUuMS4xKVwiIEFORCB0YWdzOlwiY29uc29sZVwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDM4MTc1NTc3NzIwfQ== Trove is blocked on stable/kilo due to this bug: https://bugs.launchpad.net/trove/+bug/1479358 So, after every release a giant amount of patches all have to land lock step or everything is broken? That seems pretty fragile. Can we revisit whatever decision caused this issue? -Sean pbr 0.11 started enforcing that the version in the package is incremented beyond the latest release tag, so yeah, once we tagged and released 2015.1.1 pbr pukes until we land the change that updates the version to 2015.1.2 in setup.cfg. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 07/29/2015 09:49 AM, Jeremy Stanley wrote: On 2015-07-29 09:39:46 -0400 (-0400), Sean Dague wrote: On 07/29/2015 09:29 AM, Matt Riedemann wrote: On 7/29/2015 8:17 AM, Matt Riedemann wrote: [...] ValueError: git history requires a target version of pbr.version.SemanticVersion(2015.1.2), but target version is pbr.version.SemanticVersion(2015.1.1) [...] So, after every release a giant amount of patches all have to land lock step or everything is broken? That seems pretty fragile. Can we revisit whatever decision caused this issue? This came with the semver implementation in PBR 0.11, specifically the idea that if your most recent tag is higher than the version you claim to be working toward in setup.cfg then something is terribly wrong and PBR should throw its hands up in the air until you fix your config. Useful in theory, but racy in practice (especially when you have one team of people pushing tags and a different team approving updates to the repo's setup.cfg file). A suitable compromise might be to add a knob to PBR (probably via a directive in setup.cfg) to emit a warning and fall back on version guessing as if the version entry were not present at all. Right, because otherwise we need to account for 1 to 2 days of gate blockage after every stable release, which seems broken by design. -Sean -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] stable/kilo (and master grenade) will be blocked until version bumps on kilo are merged
On 7/29/2015 8:17 AM, Matt Riedemann wrote: stable/kilo and grenade (master) jobs are going to be blocked for some projects until the kilo 2015.1.2 version changes are merged: https://review.openstack.org/#/q/I180de9d4f1f4ae385682ce40a3a695eb3acc4c43,n,z So avoid rechecks for grenade failures until these are merged (at least nova and ironic at this point). The error is like this during devstack setup: ValueError: git history requires a target version of pbr.version.SemanticVersion(2015.1.2), but target version is pbr.version.SemanticVersion(2015.1.1) http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVmFsdWVFcnJvcjogZ2l0IGhpc3RvcnkgcmVxdWlyZXMgYSB0YXJnZXQgdmVyc2lvbiBvZiBwYnIudmVyc2lvbi5TZW1hbnRpY1ZlcnNpb24oMjAxNS4xLjIpLCBidXQgdGFyZ2V0IHZlcnNpb24gaXMgcGJyLnZlcnNpb24uU2VtYW50aWNWZXJzaW9uKDIwMTUuMS4xKVwiIEFORCB0YWdzOlwiY29uc29sZVwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDM4MTc1NTc3NzIwfQ== Trove is blocked on stable/kilo due to this bug: https://bugs.launchpad.net/trove/+bug/1479358 -- Thanks, Matt Riedemann __ 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
