Re: 1.6 release -- where I'd like us to go from here.

[Thien-Thi Nguyen]

   From: Rob Browning <address@hidden>
   Date: Sun, 14 Apr 2002 23:39:48 -0500

     (1) bugs/optargs-bound-gone

current state "fixed: Marius Vollmer <address@hidden>, 2002-02-22" does
not address the problems of the bug reporter, whose responsibilities in
the process include closing it.  that hasn't happened yet.

calling this bug (fixed or not) not release-critical means a release is
valued for its event and not its consequence.  in this case consequence
is that people for whom (ice-9 optargs) worked before w/o problems now
have problems if they use this release.  probably release-critical tags
should not be used to gate a release, but should only be applied once
given some criteria.

     (4) tasks/TODO - convert bug tracking/summarization process

         Is this really 1.6 release critical?  It seems like it could be
         moved to a 1.8 section or "Eventually" to me, but I may be
         missing something.  For 1.6, it seems like we can easily just
         create copy BUGS by hand if this is likely to hold things up any
         longer.

just done:
- moved the mailing list scanning subtree to Eventually
- moved "write render-bugs, add to mscripts or guile-tools" to
  Eventually (will documented "1mo timeout guideline" shortly)
- replaced it w/ "write stub render-bugs" and did it.

so now the only two items are to run render bugs at the right time in
the release process (why don't you claim these?).

     (5) tasks/TODO - write build/bugs-triage.text
                    - complete build/stability.text [ttn]
                    - make sure all bugs have required headers

         Are these really 1.6 release critical?  I'm inclined to want to
         move these to the 1.8 section as well.  While I think these
         improvements are important, and should certainly be finished by
         1.8, they don't seem like anything that can't wait until 1.6.2,
         etc.

the gist of these efforts is really just to capture some of the writings
that you've recently done (and are now doing) wrt release process "in
general".  if you think the writings that you have or are imminently
about to checkin cover the relationships between release and bugs, and
release and stability (authoritatively), why not claim these tasks and
either use excerpts from the writings to organize those thoughts, or
reshape the tasks so that your writings fulfill their spirit.

in other words, the release manager role also defines criteria for
determining "what is critical to a/this release" and these need to be
clearly explained somewhere.  everyone is expected to apply their
judgement using these criteria (including the release manager :-),
and the release manager is consulted for clarification.  this is how you
get slack into the system.

thi