Open Stack

Excerpts from Aditya Vaja's message of 2016-11-16 01:50:39 +0530:
> Hi All,
> [Redirect to a more specific mailing list if applicable]
> I’m trying to tag a release on the networking-bigswitch project for stable/newton branch and see if it pops up on https://tarballs.openstack.org/networking-bigswitch/ [https://tarballs.openstack.org/networking-bigswitch/] . Unfortunately, it shows tarballs with ‘dev’ in the name i.e. not the tagged release, but regular builds I guess.
> To back up a few steps, this is what I did after switching to the stable/newton branch, following the steps here [1]: bsn at bcf-controller-vm:~/work/networking-bigswitch$ git tag -s -m "initialize newton branch" 9.40.0 -u "Big Switch Networks" bsn at bcf-controller-vm:~/work/networking-bigswitch$ git push gerrit 9.40.0 Counting objects: 2, done. Delta compression using up to 4 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (2/2), 575 bytes | 0 bytes/s, done. Total 2 (delta 0), reused 0 (delta 0) remote: Processing changes: refs: 1, done To ssh://wolverineav@review.openstack.org:29418/openstack/networking-bigswitch.git * [new tag] 9.40.0 -> 9.40.0 bsn at bcf-controller-vm:~/work/networking-bigswitch$
> I’m waiting for something to show up in the ‘release’ section on zuul: http://status.openstack.org/zuul/ , but nothing. Any tips on debugging?
> I tried 'git os-job 9.40.0’ which opens browser with the following link [2], but it returns a message ‘File not found’.
> Aditya via cloudmagic
> [1] https://wiki.openstack.org/wiki/Sahara/How_To_Release [https://wiki.openstack.org/wiki/Sahara/How_To_Release] [2] http://logs.openstack.org/dd/ddcd66da6a671fabd3356c006b17b187dc287164/ [http://logs.openstack.org/dd/ddcd66da6a671fabd3356c006b17b187dc287164/]

Looking at the openstack/networking-bigswitch repo upstream I see
a few issues with the way the release settings are configured, but
I think we can fix them all relatively easily.

1. The tagged release isn't on the newton branch.  In fact, it's
   not on a named branch at all as far as I can tell.

$ git log --graph --oneline --decorate origin/master
origin/stable/newton 9.40.0
* c4b48fb (origin/stable/newton) initialize newton branch with correct
* version and spec file
| * 463afdc (tag: 9.40.0) initialize newton branch with correct version and spec file
|/
| * b244d09 (HEAD -> master, origin/master, origin/HEAD) Revert "initialize newton branch with correct version, spec file"
| * 0b6bdfe initialize newton branch with correct version and spec file
|/

$ git branch --contains 9.40.0
(no output)

Normally we would have wanted the stable/newton branch created from
an existing tagged release (tag master, then create the branch from
the same commit). One way to fix this would be to recreate the
existing branch, but gerrit doesn't currently know about the commit
that *has* been tagged so I'm not sure what effect recreating the
branch would have. The best guess as to why is that the commit you
tagged locally was pushed, with the tag, to gerrit, but didn't go
through the review process.

I think your best course of action will be to write off 9.40.0 as a bad
release, fix some of these issues, and then tag a new 9.40.1.

2. The way you're doing versioning is non-standard.  You should
   either use tags or hard-coding the value in setup.cfg, but not
   combine the approaches.

We've converted all of the official projects to rely only on tags
because it eliminates the opportunity for a version number to
accidentally regress on a given branch (pbr calculates the version
correctly based on the most recent tag and the number of commits
after it). To fix this, I suggest removing the "version" entry from
your setup.cfg on all branches and then we can sort out the tag
situation mentioned in item 1.

3. The actual version numbers being used are not really ideal.

We've been trying to get everyone to use semantic versioning as a
standard (http://docs.openstack.org/developer/pbr/semver.html).
That said, as an unofficial project you're not required to follow
that standard by the upstream community. Either way, at this point
I think you want to stick with 9.40 as the base version for the
newton branch.  Maybe consider moving to SemVer for ocata.

4. The name field in the setup.cfg is set to "bsnstacklib" rather
than "networking-bigswitch".

I'm curious to know what led to that choice. It will undoubtedly
cause confusion for downstream packagers who are looking for files
in http://tarballs.openstack.org/networking-bigswitch/ because I
think when the packaging jobs are set up the files will go to
http://tarballs.openstack.org/bsnstacklib/ instead -- they will at
the very least use "bsnstacklib" instead of "networking-bigswitch"
within the tarball filename, just as the name results in the PyPI
URL being https://pypi.python.org/pypi/bsnstacklib. As an alternative
example, see http://tarballs.openstack.org/networking-cisco/ and
https://pypi.python.org/pypi/networking-cisco. You're the best judge
of what name consumers expect, though.

5.  The release jobs aren't set up on the repository, which explains
why there are no versioned tarballs available.

The tarballs you do see are created automatically from the tip of
each branch as changes are merged. You should look through the
project creator's guide and take the steps you need to set up the
relevant release jobs
(http://docs.openstack.org/infra/manual/creators.html).  After that
is done, pushing a signed tag to the gerrit repo will automatically
trigger jobs to build and publish versioned tarballs, Python sdists,
Python wheels, release notes, etc. If you do decide to change the
name of the deliverable in item 4, you'll need to make sure you set
up the new project on PyPI with the right name.

After all of these issues are resolved, we can tag a 9.40.1 release
on the new tip of stable/newton and let the CI system build the
packaging files (the versioned tarball, upload to PyPI, etc.). Let me
know when you're ready to do that, and I'll help you double check the
process to avoid any issues.

Doug