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@bcf-controller-vm:~/work/networking-bigswitch$ git tag -s -m "initialize > newton branch" 9.40.0 -u "Big Switch Networks" > bsn@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://wolverin...@review.openstack.org:29418/openstack/networking-bigswitch.git > * [new tag] 9.40.0 -> 9.40.0 > bsn@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev