[Libguestfs] How it works - libnbd / nbdkit upstream releases

[Richard W.M. Jones]

Hi Eric,

I thought it would be more useful to document (semi-)publicly how I do
upstream releases of libnbd / nbdkit.  None of this is set in stone,
it's just how I do it right now.

For upstream development (master) branch dot releases:

 - Edit configure.ac and update the last field of AC_INIT

 - This should all pass:

   ./configure
   make distclean
   ./configure --enable-gcc-warnings --enable-python-code-style
   make
   make check
   make check-valgrind

 - This compares the files in the dist tarball with the files in git
   and is useful to make sure EXTRA_DIST isn't missing anything:

   make dist
   make maintainer-check-extra-dist

 - I usually copy the tarball to another machine to make sure it
   compiles.

 - Once you're happy the tarball works, commit & tag it:

   make maintainer-commit
   make maintainer-tag
   git push ; git push --tags

 - GPG sign the tarball with a detached signature and upload it to the
   website.  (I will talk to you about this separately).

   Note that since the tarball contains generated files, especially
   for libnbd, we don't rely on the automatically generated tarballs
   in gitlab.

For a Fedora Rawhide release, which usually follows from the above:

 - fedpkg clone -B libnbd   # or nbdkit
   cd libnbd/rawhide

 - Edit libnbd.spec to set the updated version, and add a %changelog
   entry.  See previous commits for examples.

 - Upload the sources:

   fedpkg new-sources libnbd-*.tar.gz libnbd-*.tar.gz.sig

 - Commit, push it and build:

   fedpkg commit -c
   fedpkg push
   fedpkg build
   #fedora update   # only required on non-Rawhide branches

Check the other Fedora branches.  At the moment they are following the
stable branch, only Rawhide follows the development branch.  But at
other times it is possible that a Fedora release branch might be
following the development branch (because our upstream releases don't
synchronise with Fedora).

For an upstream stable branch (stable-1.xx) dot release:

 - Cherry pick only patches which are any of:

   * Bug fixes
   * Simple code refactoring that don't introduce new features.

 - Definitely don't introduce new features in the stable branch.

 - I try to avoid introducing new tests in the stable branch, because
   tests can fail and we don't want someone upgrading along the stable
   branch to have build issues.

 - I usually like to keep the commits in the same order as the
   development branch as much as possible, but it's not a hard
   requirement.

 - I find it very helpful to use git cherry-pick -x option since it
   makes it easy to search git log to see what commits have been
   backported (especially useful when commits depend on each other).

 - Proceed per development release as above.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/