whoops, forgot to commit this a couple months ago. add a few more notes.

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
(<code>cd distrib/notes/amd64; make USETOOLS=no</code>), 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-&lt;version&gt; 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
about how you really ought to just remove this ridiculous self-indulgent
section from the notes entirely).
Note: the "changes" part of this should be taken from an mdoc file that
is generated from <code>htdocs/releases/formal-&lt;BLAH&gt;/changes&lt;VERSION&gt;.xml</code>.
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-&lt;blah&gt;, 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 <code>htdocs/layout.xml</code> and add an entry for
the new page.
2. Update version numbers in <code>gnu/usr.bin/groff/tmac/mdoc.local</code> and
sys/sys/param.h. Add new CHANGES file to doc/README.files, updating
release numbers while there. Make sure <code>doc/LAST_MINUTE</code> is zeroed out
and adjust version number.
3. Note changes from steps 1 and 2 in doc/CHANGES-&lt;whatever&gt;
4. <code>cvs -f rtag -a -rnetbsd-5 netbsd-5-0-RELEASE src xsrc</code>
If something needs to be retagged after the fact:
- Change &lt;file&gt; on the netbsd-5 branch.
- <code>cvs tag -d netbsd-5-0-RELEASE &lt;file&gt;</code>
- <code>cvs tag -rnetbsd-5 netbsd-5-0-RELEASE &lt;file&gt;</code>
5. Add tag (netbsd-5-0-RELEASE) to <code>~builds/etc/archlist</code> on build.netbsd.org
Add tag to <code>AB_STICKY_TAG_LIST</code> in <code>~builds/etc/autobuild.conf</code>. Note that
these files are revision controlled (<code>localsrc/releng/autobuild/etc</code>), so
the proper order is to commit your changes in localsrc and then cvs up
(it pulls from anoncvs@nbcvs) on build.netbsd.org.
6. Add tag to <code>~builds/etc/build_order</code> like: <code>netbsd-5-0-RELEASE:N:N</code>
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
<code>run_builds.sh</code> and restart the builds to get this to
take effect, or you could insert it *after* the top line and it will be
the next build (which doesn't require killing <code>run_builds.sh</code>.
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-&lt;release&gt;.iso (for 6.0 and beyond, NetBSD-&lt;version&gt;-&lt;port&gt;.iso)
Create hashes for ISOs (<code>cksum -a sha512 NetBSD* > SHA512</code>)
9. rsync to nbftp. It goes to a staging dir in /pub/NetBSD/misc/releng first.
rsync -avu --progress --port 874 --password-file /home/builds/.rsync &lt;path-to-top-level-release-dir&gt; builds@ftp.netbsd.org::builds/
This will upload the files to <code>ftp.NetBSD.org:/pub/NetBSD/misc/releng/</code>.
After that, get admins to create <code>/pub/NetBSD/NetBSD-&lt;release&gt;</code> and
<code>/pub/NetBSD/iso/&lt;release&gt;</code> directories for you, owned by builds:builds.
Once these have been made, move images/* to the iso directory and symlink to "iso" and "images" in the main release directory, and move the rest
to the main release directory.
10. create torrents
In the images directory:
for i in NetBSD-* ; do
maketorrent-console http://tracker.netbsd.org:6969/announce $i
done
11. Get admins@ to add the torrent directory to <code>~torrent/runbt</code>.
*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.
<code>localsrc/security/programs/rel-hashes.sh</code>
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.
- Commit release's HTML file in htdocs/releases/formal-&lt;blah&gt;
- Update htdocs/share/xml/misc.ent (release.*)
- Add htdocs/support/security/patches-&lt;blah&gt;
- Update htdocs/releases/formal-&lt;blah&gt;/index.xml
- Update htdocs/mirrors/torrents/
- Update htdocs/releases/formal.xml
- Top-level regen of everything
- Update htdocs/changes/index.xml
- Update htdocs/index.html
- Port pages in wikisrc -- sed? :\ (don't bother with xen)
- Update htdocs/developers/features/
- Update htdocs/docs/guide/en/chap-fetch.xml
16. Update <code>/pub/NetBSD/README</code> 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
* Update src/share/misc/bsd-family-tree
* Update src/usr.bin/calendar/calendars/calendar.netbsd
create netbsd-5-0 branch:
cvs rtag -a -b -rnetbsd-5 netbsd-5-0 src xsrc