[N.B.: These notes may no longer reflect reality]

Seamonkey build/release
I. Build System 

    A. Developer

       For mozilla, this info is up to date at http://www.mozilla.org/build/
       For commercial, this info is http://warp/projects/client/seamonkey/

       The process for each platform is basically the same:
           * Configure your machine with the proper toolset
           * Checkout a script or set of scripts
           * Use the scripts to checkout the correct source and build the tree

       1. Unix

          Thanks to Steve Lamm and Chris Seawood, we have a great way to 
          configure unix builds: http://webtools.mozilla.org/build/config.cgi

          Thanks to the efforts of Ramiro and Chris McAfee, the default options
          are pretty sane.

          a. mozilla
             * cvs -d :pserver:user%netscape.com@cvs.mozilla.org:/cvsroot 
               co mozilla/client.mk
             * cd mozilla; gmake -f client.mk        

             Note that if you have a built tree already, this will re-checkout
             the source code and use automatically generated dependency
             files to do a depend build.

             Other useful targets are:
                 * clean, clobber_all: removes all files specified in the
                   $(TRASH) macros defined in the local makefiles.
                 * cleansrcdir: removes all object files and generated files
                 * checkout, pull_all: check out the source only.
                 * build: build only (assumes a checked out tree).

          b. commercial

             Building a commercial tree assumes that you've built a 
             mozilla tree in the directory you're going to check out
             the ns tree.
        
             * cvs -d :pserver:user@cvsserver:/m/src co ns/client.mk
             * cd ns; gmake -f client.mk
             
       2. Windows

          a. mozilla
             
             Basically, the same as unix, though not as flexible.
             
             * cvs -d :pserver:user%netscape.com@cvs.mozilla.org:/cvsroot 
               co mozilla/client.mak
             * cd mozilla 
             * nmake -f client.mak

          b. commercial
             * cvs -d :pserver:user@cvsserver:/m/src co ns/client.mak
             * cd ns
             * nmake -f client.mak pull_netscape_commercial build_all

             Ironically, build_all only builds the commercial client, so you 
             still have to build mozilla by hand before starting the
             commercial build..

       3. Mac
          a. mozilla
             * cvs checkout mozilla/build/mac
             * run PullNGlayout.pl to pull the source
             * run BuildNGlayoutDebug.pl to build a debug tree

          b. commercial
             

    B. Release

       Why is the release process different than the developer process?
       There are a few reasons: developers don't generally care about 
       packaging, developers generally want debugging symbols in their 
       binaries, not all developers want to work on all component 
       integration.

       So, the automation written for release builds does *basically* the
       same thing that developer builds do, with the following differences:
            * Release builds create .xpi files and installers
            * Release builds incorporate other, pre-built components
              (security, spellchecker, flash, jvm, etc.)
            * Release builds strip debugging symbols from the binaries and
              push them to the talkback server, and also generate an id
              to associate talkback incidents to the correct debugging
              symbols

       1. Unix
          For daily releases, we use some automation scripts that are
          descended from legacy code written to satisfy 2.x-4.x releases.
          We are working to clean this up so that it reflects the process
          that developers use, rather than manually doing the steps 
          that client.mk does automatically and transparently.

          The constantly improving, currently in use, scripts are:
          ns/build/unix/verification/seamonkey-spawn
          ns/build/unix/verification/seamonkey-build

          seamonkey-spawn spawns builds on all the machines we do unix
          builds on (currently only linux and solaris 2.7 for seamonkey).

          seamonkey-build is the meat of the process and does all the build
          and delivery, forgoing the use of client.mk in favor separately
          configuring and building.

          This single script does both the mozilla.org releases and the
          internal commercial build deliveries.

          There are some differences in configure options from the default:
          --disable-tests to avoid unnecessary building of non-released stuff
          --with-extensions=default,irc to get the all-important chat client
          --without-jpeg --without-zlib --without-png, so we build our own,
          rather than relying on an existing set of system libraries.


       2. Windows

          Luckily, we didn't have much in the way of legacy windows automation,
          affording the opportunity to write something that fits the seamonkey
          build process better.

          cm/client/windows/build-verification.pl (in /m/src) runs the 
          windows releases to mozilla.org and the internal commercial.

       3. Mac
          
          We don't quite have the applescript someplace readily viewable,
          but trust me, it's really good!

    C. Mechanics, how to.
       1. Add files to build

          * cvs add the file to the correct repository

          a. unix

             * Add the new source file to the appropriate *SRCS macro
               in Makefile.in (this is later used to generate Makefile).

          b. windows

             * For c and c++ files, add the new target object to
               C_OBJS or CPP_OBJS macro as appropriate.
             * For idl files, add the idl source file to the XPIDLSRCS macro.

          c. mac

             * for new source files, add the new file to the list of files 
               getting built in the CodeWarrior project file associated with 
               the module you're building; add it to both the optimized and 
               release versions of the product.
             * for new header files and resources, add the new file to the 
               MANIFEST file for export.
             * for new project files, create the project and add it to the
               list of built projects in 
               mozilla/build/mac/NGLayoutBuildList.pm, or 
               ns/build/mac/CommercialBuildList.pm

       2. Add files to installer packaging.

          Once you get your code built, naturally you want to include it in
          the shipped product. To do this, you have to make sure that your
          binaries and resource files (xul, gif, jpeg, png, whatever) are
          included somehow in
          mozilla/xpinstall/packager/packages-mac
          mozilla/xpinstall/packager/packages-unix
          mozilla/xpinstall/packager/packages-win

          or

          ns/xpinstall/packager/packages-mac
          ns/xpinstall/packager/packages-unix
          ns/xpinstall/packager/packages-win

          You can even test the installer creation process yourself once
          you've done a build, and you're on windows, and you have zip.exe
          in your path, just run:
          mozilla/xpinstall/wizard/windows/builder/build.pl

          and you'll end up with an installer in
          mozilla/dist/win32_d.obj/install

II. Verification Process / Development Model
    A. Verifications
       Opportunity to
         * look for regressions.
         * close the tree and focus on blocking bugs, if any are found.
         * verify that optimized builds still work.
         * verify that the packaging manifests are still up-to-date enough.

    B. Tinderbox/Bonsai
       * Helps make sure code builds XP
       * Gives an easy way to track checkins and associate them 
         with bloat/bustage
       * Gives very visible place to post checkin rules.

    C. Sheriffs
       1. Why do we need a sheriff?

       2. Why isn't there just one sheriff, like there used to be?

       3. Sheriff's tools:
          * Bonsai (open/close the tree to checkins)
          * the hook: http://bonsai.mozilla.org/toplevel.cgi?treeid=SeaMonkey
            or http://warp.mcom.com/webtools/bonsai/toplevel.cgi
          * Tinderbox!

III. FAQs
     A. CVS
        1. lock files
           a. for mozilla, page-leaf@mozilla.org, or file a bugzilla bug
              against server operations (http://bugzilla.mozilla.org)
           b. internally, x4444 or helpdesk request
        2. branches
     B. Tools
        1. lxr
        2. bonsai
        3. tinderbox
        4. IRC/AIM
     C. Resources