X Strike Force XFree86 SVN commit: r1894 - /
Author: branden
Date: 2004-09-28 12:51:34 -0500 (Tue, 28 Sep 2004)
New Revision: 1894
Modified:
HACKING
Log:
Add "Release Checklist" section.
Modified: HACKING
===================================================================
--- HACKING 2004-09-28 17:24:12 UTC (rev 1893)
+++ HACKING 2004-09-28 17:51:34 UTC (rev 1894)
@@ -353,6 +353,97 @@
non-free fonts. The "prune-non-free" script in the Debian source package of
XFree86 is designed to handle those.
+Release Checklist
+-----------------
+
+The following is a best-practice recommendation for procedures to follow when
+doing an XFree86 package release.
+
+* Use "svn diff" to confirm that there are no unexpected changes or regressions
+ in the release you are about to do.
+
+ Examples:
+
+ When preparing a release to unstable, you might run a command like this:
+ $ svn diff svn://necrotic.deadbeast.net/xfree86/trunk svn://necrotic.deadbeast.net/xfree86/branches/4.3.0/sid
+
+ When doing a security release for Debian stable, on the other hand, it's wise
+ to compare against the tag of the previous stable release, so that you can be
+ confident no extra, non-security-related code crept in:
+ $ svn diff svn://necrotic.deadbeast.net/xfree86/tags/4.1.0-16woody2 svn://necrotic.deadbeast.net/xfree86/branches/4.1.0/woody
+
+* Edit debian/changelog to set the package version correctly (i.e., no "+SVN"
+ string). Set the release urgency if necessary; if the urgency is not "low",
+ add a changelog item to the top of the entry justifying the elevated urgency.
+ This helps Debian release managers understand your reasons for requesting
+ expedited processing.
+
+* Ensure no unwanted references to "+SVN" package versions linger in the tree,
+ particularly in debian/control.
+
+* Commit any uncommitted changes.
+
+* Build the branch in an up-to-date chroot corresponding to the distribution
+ you're releasing to ("unstable" in the typical case). Do a full build -- no
+ "-B" business here.
+
+* Once the (binary) packages are built successfully, test them. This includes:
+ + Installing them and running them. This especially includes the X server and
+ xterm, as both of these are widely used and exercise many parts of the X
+ Window System distribution.
+ + Ideally, we'd confirm that every bug we claim to fix is really fixed.
+ Unfortunately, many bugs are against particular drivers in the X server or
+ are difficult for a given individual to reproduce given limited access to
+ hardware. Attempt to focus on a few classes of bugs:
+ - Release-critical bugs: If an RC bug is being fixed, the upload is probably
+ going to be of elevated urgency. It is very sloppy to not actually
+ achieve something you're claiming as justification for that elevated
+ urgency!
+ - Regressions: bugs we had fixed in a previous release but managed to
+ un-fix.
+ - Paper bag bugs: Occasionally a real boner will happen with the packages,
+ which results in a few dozen people filing duplicate reports about the
+ same issue, generally within a day or two of a package's release to
+ unstable. If this release is to fix a paper bag bug, please ensure it's
+ actually fixed.
+ + Use a chroot to test upgrades of every package from the previous unstable
+ release.
+ + Use a chroot to test downgrades of every package back to the previous
+ unstable release.
+ + Use a chroot to test installs of every package in an environment that has
+ never seen them installed before.
+ + Use a chroot to test purges of every package. (Purging is a strict superset
+ of removal, so this exercises normal removal as well.)
+
+* If the package has built and passed muster with the above battery of tests,
+ sign and upload the release.
+
+* Once you have received the "accepted" message from the Debian archive robot,
+ tag the release. If the package was "rejected", you may need to repeat some
+ or all of the above steps depending on the reason. If the package was
+ deferred for manual handling (the robot calls this "NEW"), make no further
+ changes to the branch until the archive administrators either accept or reject
+ the package.
+
+ Example of tagging an accepted upload:
+
+ $ svn copy svn://necrotic.deadbeast.net/xfree86/branches/4.3.0/sid svn://necrotic.deadbeast.net/xfree86/tags/4.3.0.dfsg.1-8
+
+* Merge your final changes to the branch back to the trunk. This should consist
+ only of your changes to debian/changelog.
+
+ Example:
+
+ $ svn merge -r 1999:2000 svn://necrotic.deadbeast.net/xfree86/branches/4.3.0/sid $your_working_copy/trunk
+ $ svn commit
+
+* Inaugurate new development on the trunk. Start a new changelog entry (I use
+ "dch -i"), setting the package version to the one just released and adding the
+ suffix "+SVN". Edit the CHANGESETS file and remove all the items (but leave
+ the explanatory text and the Vim modeline). Commit these changes.
+
+* Update NEWS.xtml to announce the release.
+
$Id$
vim:set ai et tw=80:
Reply to: