Open Stack

On 18 March 2015 at 03:03, Doug Hellmann <doug at doughellmann.com> wrote:
> Now that we have good processes in place for the other Oslo libraries, I
> want to bring pbr into the fold so to speak and start putting it through
> the same reviews and release procedures. We also have some open bugs
> that I'd like to find someone to help fix, but because we can't actually
> release from the master branch right now working on fixes is more
> complicated than it needs to be. I don't want to focus on placing blame,
> just understanding where things actually stand and then talking about
> how to get them to a better state.

+1.

> From what I can tell, the main problem we have in master right now
> is that the new semver rules added as part of [1] don't like some
> of the existing stable branch tags being used by projects. This
> feels a bit like we overreached with the spec, and so I would like
> to explore options for pulling back and changing directions. It is
> quite likely I don't fully understand either the original intent
> or the current state of things, but I want to start the discussion
> with the hope that those with the details can correct my mistakes
> and fill in any gaps.

My understanding is different. The thing preventing a release of trunk
was that pbr and PEP-440 ended up (after lots of effort!) at odds, and
pip strictly implements PEP-440.

The key change is to tweak the generation of versions when pre-release
tags are in play.

Given this state:
commit X
commit Y tagged 1.2.3.alpha1
commiy Z tagged 1.2.2

PEP-440 says that 1.2.3.alpha1.dev1
is legitimate

but we'd chosen to do 1.2.3.dev2 - discarding the .alpha1 and walking
back to the last tag.

I don't recall the exact detail of the conflict here - but its all in
-infra channel logs if that matters. Making the change should be
pretty straight forward.

A second but also mandatory change is to synchronise on the final
pre-release tag definitions in PEP-440, IIRC that was just 'rc' ->
'c'.

With those done we should be able to release trunk.

*all* the extra bits are extra and should not hold up releases
....

On 'do what I say' for version numbers, pbr still permits that: if you
tag, it will honour the tag. I'd like eventually to make it error
rather than warn on weirdness there - both the requirement that things
be in canonical form, and the insistence on honouring semver (no API
breaking .minor releases!) - are aids for interop with pip and
PEP-440. To reiterate the current situation (AIUI) is warn not
enforce, and no action should be needed here.

> Some of the other special casing seems to be for TripleO's benefit
> (especially the stuff that generates versions from untagged commits).
> Is that working? If not, is it still necessary to have?

Huh, no. Thats all about unbreaking our behaviour in the gate. We've
had (and can still have with current released) cases where we end up
installing from pypi rather than the thing we're testing, if the
version numbers align wrongly. (All due to accidentially rewinding
versions in the presence of pre-release versions). Pbr has generate
versions forever. It just generates completely broken ones in the
released code. Yes broken - they go backwards :).

> The tag-release command isn't necessary for OpenStack as far as I
> can tell. We have a whole separate repository of tools with
> release-related scripts and tooling [2], and those tools automate
> far more than just creating a tag for us. I don't expect any OpenStack
> project to directly use a pbr command for creating a tag. Maybe we
> missed the window of opportunity there? How much of that work is done?
> Should we drop any remaining plans?

I think we can defer this part of the conversation.

> Did I miss anything that's currently broken, or needs to be done before
> we can consider pbr releasable for liberty?

We should update the spec as we do this.

-Rob

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