File:  [NetBSD Developer Wiki] / wikisrc / releng / release-prep.mdwn
Revision 1.1: download - view: text, annotated - select for diffs
Sat Mar 16 22:24:27 2013 UTC (13 months, 1 week ago) by wiki
Branches: MAIN
CVS tags: HEAD
web commit by riz: Committed unchanged cut-and-pasted text from blef.org/releng.txt

This file contains various information about doing releng-y stuff.

==========

Creating a branch:

   cvs rtag -a netbsd-5-base xsrc src
   cvs rtag -a -b -rnetbsd-5-base netbsd-5 src xsrc

   On the newly-created branch:
     Add doc/CHANGES-5.0
     Adjust doc/README.files and doc/LAST_MINUTE 
     Adjust gnu/usr.bin/groff/tmac/mdoc.local and sys/sys/param.h

   On the trunk:
     Update doc/BRANCHES
     Move doc/CHANGES to CHANGES.prev
     Update mdoc.local and param.h for .99.1.

==========

Cutting release candidates and releases:

1. Make sure release notes are updated in distrib/notes

   A good starting point is to generate notes for a sample port
   (cd distrib/notes/amd64; make USETOOLS=no), read the HTML file, and look
   for things that need updating.

   Stuff you'll definitely need to do:
   - Brace yourself.  The sheer amount of useless information from days
     of yore will blow you away.  You'll even start to think "you know, it's
     possible someone actually _does_ want to read about splitting
     distribution sets so they'll fit on floppies."
   - Update Dd (should be the day the release is tagged)
   - Update version numbers
   - Add mention of the latest CHANGES-<version> file in the "Release
     Contents" section
   - List changes present in this release
   - Adjust known issues section as necessary
   - Adjust compatibility issues section as necessary
   - Check the {core,portmasters,releng,developers} lists (while grumbling 
     bout how you really ought to just remove this ridiculous self-indulgent
     section from the notes entirely).
   - Check to make sure that the IP addresses of ftp.NetBSD.org are current

   Note: the "changes" part of this should be taken from an mdoc file that
   is generated from htdocs/releases/formal-<BLAH>/changes<VERSION>.xml.
   Look for ".Ss Changes Between the NetBSD" in distrib/notes/common/main
   and paste away!  You may have to make a few markup changes to the contents
   of the mdoc file, because the XML -> mdoc converter sucks.  Always check to
   make sure things are formatted as intended.

   Basically, in htdocs/releases/formal-<blah>, copy the previous release's
   XML files, adjust Makefile as necessary, and start the dull process of
   adding content.  Beware that this is a soul-sucking task, and you MUST
   RESIST THE TEMPTATION TO MENTION EVERY LITTLE CHANGE.  Try to keep it
   to a list of things that people will be excited about and will sell
   NetBSD.  Release notes != changelog.

   Don't forget to edit htdocs/layout.xml and add an entry for the new page.

2. Update version numbers in gnu/usr.bin/groff/tmac/mdoc.local and
   sys/sys/param.h.  Add new CHANGES file to doc/README.files, updating
   release numbers while there.  Make sure doc/LAST_MINUTE is zeroed out
   and adjust version number.

3. Note changes from step 2 in doc/CHANGES-<whatever>

4. cvs -f rtag -a -rnetbsd-5 netbsd-5-0-RELEASE src xsrc

   If something needs to be retagged after the fact:
   - Change <file> on the netbsd-5 branch.
   - cvs tag -d netbsd-5-0-RELEASE <file>
   - cvs tag -rnetbsd-5 netbsd-5-0-RELEASE <file>

5. Add tag (netbsd-5-0-RELEASE) to ~builds/etc/archlist on build.netbsd.org
   Add tag to AB_STICKY_TAG_LIST in ~builds/etc/autobuild.conf.  Note that
   these files are revision controlled (localsrc/releng/autobuild/etc), so
   the proper order is to commit your changes in localsrc and then cvs up
   (it pulls from anoncvs@nbcvs) on build.netbsd.org.

   If building for a branch older than netbsd-5-0, set -j1 so that set sharing
   works better, and don't forget to undo it later!  This is configured in
   autobuild.conf with the AB_SLAVE_OPTS_b[678] variables.

6. Add tag to ~builds/etc/build_order like: netbsd-5-0-RELEASE:N:N
   This means the tag will only be built once, and it won't be uploaded
   after it finishes building.  Put it at the top.  You'll have to kill
   run_builds.sh and restart the builds to get this to take effect.

7. Spend the next few hours worrying about some unforeseen or sporadic problem
   causing one or more ports to fail.  Cross your fingers and hope that you're
   spared the hassle.  If you're not so lucky, dig around and manually rebuild
   a port on one of b[678], copying the build.sh line from logs, mainly to
   preserve the -B flag's argument.  Copy the results back to build.netbsd.org
   and proceed.

8. Create ISOs (macppc, mac68k, source).  See below for instructions.
   Rename ISOs to blahcd-<release>.iso
   Create hashes for ISOs (cksum -a 512 *iso > SHA512)

11. rsync to nbftp.  Has to go to a staging dir in /pub/NetBSD-daily first.

   rsync -avu --progress --port 874 --password-file /home/builds/.rsync <path-to-top-level-release-dir> builds@ftp.netbsd.org::builds/priv/

   This will upload the files to ftp.NetBSD.org:/pub/NetBSD-daily/priv/.
   After that, get admins to create /pub/NetBSD/NetBSD-<release> and
   /pub/NetBSD/iso/<release> directories for you, owned by builds:builds.
   Once these have been made, move iso/* to the iso diectory, and the rest
   to the main release directory.

11. create torrents
   for i in *.iso ; do
   maketorrent-console http://tracker.netbsd.org:6969/announce $i
   done

   Get admins@ to add the torrent directory to ~torrent/runbt

   NOTE FROM SPZ, 2010-11-15:
   |it turns out that bittorrent can't do more than one 'allowed_dir'.
   |
   |Thus, we now have /ftp/pub/NetBSD/torrent. Please keep the permissions
   |so that mirrors can't read the contents, since the contents are duplicate.
   |
   |(This should go into releng docs probably:)
   |If you add a file that should be picked up by torrents, put it and its
   |torrent control file where it belongs and hard-link the two into the
   |appropriate directory in the torrent tree.
   |Please note that the torrent tree cannot be used to publish the torrent
   |control file via http or ftp.

12. Get security-officer@ to sign binaries and ISOs.
    localsrc/security/programs/rel-hashes.sh 

13. Give mirror-maintainers a heads up that new release binaries are available.
    This should be done 3ish days prior to the expected announce date.

14. Have admins update sup.  Wonder if anyone still uses sup anyway.

15. Update the website.

16. Update /pub/NetBSD/README to mention the new release

17. Announce the release on netbsd-announce@ and the blog.

BUILDING ISOs

The following stuff should be done on build.netbsd.org as the 'builds'
user.

Images that need to be built manually: macppc, mac68k, source

Needs to be cdrtools 2.01 (but not newer!).  The binary in ~/bin/mkisofs
will work.

cd ~/scratch
tar xzvpf /home/builds/ab/HEAD/ab-src.tgz (note -- "HEAD" is always used)

Building in src/distrib/cdrom:

Copy and fiddle with some ridiculous .mk and .conf files, adjusting for the
relevant release.

Do the following three times, changing TARGET_CD_IMAGE to macppccd, mac68kcd,
and sourcecd.

make MKISOFS=/home/builds/bin/mkisofs USETOOLS=no RELEASE=5.0 TARGET_CD_IMAGE=macppccd DISTRIBDIR=/home/builds/ab/netbsd-5-0-RC4/release/netbsd-5-0-RC4/200904142015Z all

post-release:

change name to 5.0_STABLE
5-0 branch becomes 5.0.0_PATCH

create netbsd-5-0 branch:
#### cvs rtag -a -rnetbsd-5 netbsd-5-0-base xsrc src
cvs rtag -a -b -rnetbsd-5 netbsd-5-0 src xsrc

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb