File:  [NetBSD Developer Wiki] / wikisrc / releng / Attic / release-prep.mdwn
Revision 1.11: download - view: text, annotated - select for diffs
Sat Apr 12 18:59:12 2014 UTC (4 years, 1 month ago) by snj
Branches: MAIN
CVS tags: HEAD
Let's try that again.

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 
     bout 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,
   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
   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

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></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></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 line from logs, mainly to
   preserve the -B flag's argument.  Copy the results back to
   and proceed.

8. Create ISOs (macppc, mac68k, source).  See below for instructions.
   Rename ISOs to blahcd-&lt;release&gt;.iso
   Create hashes for ISOs (<code>cksum -a 512 *iso > 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;
This will upload the files to <code></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 $i

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.

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;
    - Add htdocs/support/security/patches-&lt;blah&gt;
    - Update htdocs/releases/formal-&lt;blah&gt;/index.xml
    - Update htdocs/mirrors/torrents/
    - Update htdocs/share/xml/misc.ent (release.*)
    - Update htdocs/index.html
    - Update htdocs/releases/formal.xml
    - Update htdocs/changes/index.xml
    - Top-level regen of everything

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

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



The following stuff should be done on as the 'builds'

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


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

create netbsd-5-0 branch:

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

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb