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

[Thien-Thi Nguyen <ttn@giblet.glug.org>]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Wed, 24 Apr 2002 09:04:18 -0500

   I'm not sure I follow the the last sentence, but IMO I don't see a
   problem with having marked this bug release critical when it looked
   like it could actually be fixed (and should be if it could be).  Now
   that it doesn't look like it should be fixed, it's no longer a bug.
   Perhaps "fixed" is the wrong term.  Would "closed" or "resolved" be
   better?

sorry i was not clear.  i'm suggesting that whether or not a bug is
marked release-critical should not be the sole input on computing
whether a bug blocks release (we should take into account its state,
too), and that the tag need not be removed on bug state change:

(define (bug-blocks-release? bug)
  (and (release-critical? bug)		;; attribute
       (not (fixed? bug))))		;; state

it is sufficient to change state to influence the value of this proc,
given a release-critical bug.  while i'm at it, here's the obvious next
layer:

(define (bugs-blocking-release? all-bugs)
  (some bug-blocks-release? all-bugs))

(define (blocking-bugs all-bugs)
  (pick-mappings (lambda (bug)
                   (and (bug-blocks-release? bug)
                        (details bug)))
                  all-bugs))

so practically speaking, the steps are: (1) write "what is critical to a
release" criteria; (2) consult criteria, specializing for this release;
(3) if warranted add release-critical tag to bug; (4) fix bug and change
its state accordingly.  (1) is one-time but subject to evolution.

   How would Steve Tell close the bug, and why would he be responsible
   for that?  He reported a problem and the guile developers examined the
   issue and determined its resolution.  Once that's done, the bug is
   resolved, closed, whatever.

because Steve Tell is a user and the guile developers are ultimately
trying to serve the user.  typically, the informal way to include users
in bug-closing is to inform them of the fix and let them say "cool,
thanks" (then bask in the glow whilst consuming beverage of choice).

when the bug is internal, to some extent guile developers can emulate
the user response by running "make check" or whatever to ensure that the
fix does not upset the user experience, and fulfill the closure.

when the bug has to do w/ user-visible interface (as is the case here),
this emulation is insufficient because the likely outcome is that this
or some other user will complain, placing developers in a defensive
position, which is not fun for anyone.  there is also the clear message
that spreads into the community that developers are not responsive to
user concerns.  this is plain uncool.

all this suggests that one of the criteria for application of
release-critical tag is "does this bug involve user-visible interface?".

   In the case of bound?, it was not quite right, was documented in NEWS
   as something you shouldn't expect to stick around, and now it's going
   away.  IMO, after we make sure we have an appropriate NEWS eulogy, we
   can forget about it.

you are a release manager and sit between the developers and the users.
when you say "we" you ought to try to keep in mind everyone around you.
otherwise, you are a mere developer.

   What's the "1mo timeout guideline"?

if someone claims a task and it goes w/o update for 1mo (or whatever,
say 6 weeks), something should be done to encourage visible progress
again.  what to do?  move it to Eventually?  (this is what i did in this
case.)  put some marker on the task "like Z for ZZZZZZZ"?  revoke the
claim and mailbomb the claimant?

   OK, as I mentioned in the prev msg, I'll see if I can get this done.

cool.  it seems to me you're moving forward at a good clip.

thi

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel