Release snapshot creation Q&A.

[Michael Stone]

On IRC today, Greg asked me several questions. My responses are inline:

* How do we know when are ready to build a release snapshot?

   Immediately after we publish a new release snapshot, I enter my
   'waiting' state. In this waiting state, I wait for test results and
   for new tickets to enter the 'release queue' [1]:

     The 'release queue' is my mental device for tracking changes which
     are probably going released. It is most visible in trac in the form
     of the 'approve for release' and 'add to release' actions though it
     is slighly more inclusive because I tend to start watching tickets
     before they are ready to request approval.
     
     Tickets enter the release queue in two ways: when a coder notifies
     me or one of my delegates (presently Scott, Marco, and Chris) that
     they expect to have a qualified [2] change in the near future or
     when I or one of my delegates notices a change which can be easily
     qualified and which, in our judgement, is appropriate for release
     (e.g.  polish, small correctness fixes, debugging aids, etc.).

   Each day, I ask myself whether we have accumulated enough changes to
   enter the 'preparing' state. This judgement is based on what changes
   have been qualified, on what changes I expect to qualify in the next
   few days, on how long it has been since the last snapshot, and on the
   test results that I find on devel@ and in daily triage. 

   Eventually, I decide that I'm ready to produce a new snapshot and we
   transition to the 'preparing state', at which time the build team
   (mostly Scott, a minor contributions by me) collects all the qualified
   changes and incorporates them into the build instructions for the
   release stream. This means doing things like committing packages into
   the build repositories, updating the the release ChangeLog,
   cherry-picking any needed pilgrim patches, and finally, reviewing the
   collected changes to the build instructions against our record of the
   intended changes.

   When preparation is complete, a build engineer triggers the build and
   we move to the 'announcing' stage.

   In the announcing stage, I update the wiki instructions for testing
   the new snapshot and generally draft an email to devel@, sugar@,
   testing@, and support-gang@ explaining what to do with (and look for
   in) the new snapshot.

   [1]: http://wiki.laptop.org/go/Plan_of_Record-2008
   [2]: http://wiki.laptop.org/go/Trac_ticket_workflow#Approval_for_Release

* When we will build the next release snapshot?

   This week, probably Thursday or Friday. (Understand that, each week,
   the optimization problems gets harder for lots of interesting
   reasons.)

* How we can buttress our communications about release snapshots?

   First, by keeping your release-manager undistracted and focused on
   releasing rather than by asking him to multitask with development and
   packaging work. 

   Second, by offering other suggestions on how communication could be
   improved beyond my existing wiki, forum, mail, and whiteboard
   mechanisms.

Regards,

Michael