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 <[email protected]> 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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
