These are the steps required to cut a SystemTap release.
Check the build
See if Transifex has newer translations for po/systemtap.*. Merge them in if so. Run "make update-po" in a top-level build tree. This may update several po/* files in the source tree. Commit those changes.
Update the AUTHORS file with AUTHORS.sh.
Increment Copyright years in messages (session.cxx, staprun/common.c, stapdyn/stapdyn.cxx) if needed.
Set the productnumber in doc/SystemTap_Beginners_Guide/en-US/Book_Info.xml to match the release number.
Make sure that the NEWS file is actually current with the major changes, since this is the best base for forming the release notes.
Run a fuller-than-usual build:
configure --enable-dejazilla --enable-testapps=all make rpm make all install sudo make installcheck
The testapps part is especially important if sys/sdt.h changed from the last version, since other applications compile against that now. Regressions in compilability / performance in these sdt.h client apps should be avoided.
The remote functionality requires a bit of manual setup for testing, as for each host you must have both an automated ssh connection (e.g. via kerberos or ssh pubkeys) and an appropriate build environment, locally or using a compile server. With those conditions met, you can run an installcheck with TESTREMOTES as a comma-delimited list of hosts, e.g. "make installcheck RUNTESTFLAGS=remote.exp TESTREMOTES=foo,bar,baz"
Compile the release notes
It's easiest to get a template for the notes starting from previous SystemTapReleases. Here are the major sections to fill in:
- News blurb: 3-5 lines describing the highlights of this release. Reporters will work mostly just from this section. It may be best to do this part last, so you can summarize the rest of the release notes.
- Front-end changes: This is the general section for major changes, new command-line options, and even miscellaneous internal changes. These bulletted can come directly from the NEWS file.
- Script language changes: List the NEWS items that involve syntax changes in scripts.
- Tapset changes: List NEWS items for new probe points and tapset functions. Even better, do a "git log" on the tapset/ directory.
- Scripts examples: List the name and title of new examples. Use "git log --summary (old-release).. testsuite/systemtap.examples/" to see which files were created since the last release. If an associated '.meta' file exists for the new example, it should contain a description.
- Contributors: Get the list of names from "./AUTHORS.sh (old-release)..". Specially welcome new contributors, found with "git diff (old-release) AUTHORS".
- Tested kernels: List the platforms that were used for testing this release.
- Known issues: Evaluate whether the previous issues are still valid, and add new ones if needed.
Bugs fixed: List the sourceware bug numbers and titles that were fixed since the last release. It's helpful to query bugzilla for Resolution:FIXED and "Only bugs changed between (day after last release) and Now." (To just see the bug number and the summary for each bug, hit the "Change Columns" link and just look at the "Summary".) You may need to edit the descriptions a bit. Check also CVE's and bugzilla.redhat.com.
Create the release in git
Check that the configure and .spec files have the correct version number. The .spec should also have an appropriate %changelog entry with the current date, and a link to the SystemTapReleases wiki page (so people can find/read the release notes based on the rpm %changelog.) Add the release date to the top of NEWS.
Tag the tree with "git tag -s release-X.Y". The "-s" signs the tag with your GPG key, which should be signed by at least one of the previous maintainers to keep up the "web of trust."
Create the final source archive with "make dist-gzip", and sign it: gpg -b systemtap-X.Y.tar.gz, which will result in a .asc file.
Get the public sources in order. Use a normal "git push" to update the public git HEAD, and then send the tag with "git push origin release-X.Y". Then upload the source archive and its signature with scp to "sourceware.org:/sourceware/ftp/anonftp/pub/systemtap/releases/".
If something goes dramatically wrong with building this tarball during your own or fedora builds, it will be necessary to create a new minor version tag, tarball, and perhaps a mini-release-note.
Build the Fedora package
If you don't already have a Fedora account, then create one as described here. On your Fedora machine, you'll need to use yum to install "fedora-packager". Make sure that your certificate is saved as "$HOME/.fedora.cert", and then run fedora-packager-setup. Make sure your fedora certificate is still fresh with fedora-cert -v. Use "fedpkg co systemtap" to checkout the release infrastructure in the current directory. (Make sure that this is done away from your systemtap git path!)
Within the systemtap directory from fedpkg, the "master" branch that you end up by default in after the checkout represents rawhide. (Note that Roland's email refers to the old "devel" branch as rawhide.) We usually update rawhide and the last two stable Fedoras with each stap release.
Upload the source archive you create from dist-gzip with "fedpkg new-sources /path/to/systemtap-X.Y.tar.gz", which will also update ".gitignore" and "sources". Copy systemtap.spec from the git source tree. Consider merging fedora-only changes committed to the tree. Now run "fedpkg local" to test the rpm build locally. If this succeeds, you're ready to create the official build. If it fails, and a minor fedora-only spec-file patch makes it go, make it so. If something systemic is wrong requiring a source tarball respin, see above about a new tag, etc.
Use "fedpkg ci; fedpkg tag; fedpkg push" to commit "sources", ".gitignore", and "systemtap.spec" to the fedora repository. If there are any patches from a Fedora minor update (which are hopefully in this new upstream release already), remove then from git too. Now run "fedpkg tag" to lock in the release version. (The tags are unique, so this is our point of no return!) Finally run "fedpkg build" to submit the build to koji.
Once the devel build is successful (or while it's running if you're feeling brave), "fedpkg switch-branch" to one of the release-track fedoras. Run "git merge devel" to do all the equivalent of what you did for devel. "fedpkg ci; fedpkg tag; fedpkg push; fedpkg build".
In each release-track branch "fedpkg update" must be run to submit the package to bodhi once the build is finished. (You don't have to run "fedpkg update" for rawhide, since packages there get pushed automatically.)
Special case: Fedora minor updates
Sometimes we want to update the Fedora packages without bothering with a full SystemTap release. In this case we shouldn't have to do new-sources; we can just provide a patch file and bump the spec accordingly. First, increase the number in the "Release:" header. Then add a new "PatchN: my-update.patch" line for each new patch with a unique number N. Apply each patch in the "%prep" section with "%patchN -p1". Finally, add an entry to the "%changelog" explaining the reason for patching, and proceed to test-tag-build as normal.
Push it out and announce it
Piece of cake, right? Now all that's left is to tell the world!
Recheck the release notes one last time, in case of any last-minute closed PRs, added samples, NEWS blurbs. Next send out the release notes to email@example.com , and CC firstname.lastname@example.org and email@example.com .
Update SystemTapReleases for the new version with links to the source archive, the git tag, and the archived release notes. If you like, you can update our Wikipedia page with the new version number too.
Formally begin the next release's development cycle by bumping the version numbers. The files configure.ac, runtime/staprun/configure.ac, and testsuite/configure.ac have the release version number near the top, which should be updated to the new release version. Save those changes and run autoconf. If autoconf gives errors about mismatched versions, then you may need to run autoreconf instead. Update systemtap.spec. Near the top is a "Version:" line to update, and then if you like add a placeholder entry to the "%changelog" section, following the previous entries as a template.