[openstack-dev] [oslo][pbr] fixing up pbr's master branch

Doug Hellmann doug at doughellmann.com
Tue Mar 17 14:03:04 UTC 2015


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.

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

It looks like [1] had several goals. It was meant to fix the
automatically generated version numbers for untagged revisions,
bring us up to standard with current pip rules for version numbers,
improve our support for distro version number generation, and enforce
semver automatically by looking at comments on commits when creating
a new tag.

Is it the last part that's "broken"? Can we make pbr just "do what
I say" with version numbers, and build a standalone tool (maybe
installed as part of pbr) for suggesting tags using whatever rules
we like? That would be like the proposed next-version command, but
not invoked through setup.py. I don't actually care what the UI is,
but I do think we want any rules about what versions are "allowed"
ignored when the *existing* tags are parsed, so moving them out of
the setuptools commands entirely seems like an easy way to ensure
that.

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?

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?

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

Doug


[1] http://specs.openstack.org/openstack/oslo-specs/specs/juno/pbr-semver.html
[2] http://git.openstack.org/cgit/openstack-infra/release-tools/



More information about the OpenStack-dev mailing list