Open Stack

Excerpts from Robert Collins's message of 2015-03-19 09:15:36 +1300:
> 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 wonder if it had to do with Oslo's alpha releases? Since we're no
longer doing that, do we still care? Are we still actually "broken"?

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

How do we use those?

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

OK, so the problem was with installing packages with "bad" versions,
rather than building them in the first place?

I thought maybe someone closer to the issue would remember the
details. I should probably just try to use trunk pbr and see where
it's failing, if at all.

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

By pre-release do you mean things with "alpha" in them, or do you mean
commits that were made after a release tag?

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

Yes, it would be really good to have a concrete list of things we need
to bring master back into a working state. It sounds like we're closer
than I expected, which is good.

Doug

> 
> -Rob
>