Open Stack

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 <sean at 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