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

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

[Rob Browning]

For the duration of this message I'm just going to presume that no one
was too scandalized by the "release process requirements" in my
previous message and is mostly OK with the plan I outlined.  If that's
not true, then we'll have to revise the following accordingly.

While it's too late for the 1.6 release to completely follow the plan
I outlined, I'd like to propose that from this point forward, we
proceed as if we *had* been following that plan, though I'd like to
first review all the currently listed 1.6 critical bugs and TODO
items.  Once we've finished that, I'd like to suggest we immediately
start following the release requirements and process I outlined.

Before reviewing the release critical items, I'd like to (re)state
right up front that I feel like 1.6 is such an improvement over 1.3.4
and 1.4 that even if we released guile in its current state, it would
be a major improvement for most people.  The good work everyone here
has been doing really becomes obvious when you watch someone who's
used to 1.3.4 or even 1.4 start messing with 1.5, see them look
through the new documentation, etc.  There are going to be migration
problems, and other issues; I'm sure of that, but we can always follow
1.6.1 up with regular 1.6.X point releases to fix whatever we've
missed, and we can improve our documentation and web info as needed to
help people with the transition.

Here are the things currently listed as holding up the 1.6 release:

  (1) bugs/optargs-bound-gone

      Marius: you discussed a fix for this in email, but also mention
      that it's functionality is fairly easily worked around via
      default value -- so are we fixing it for 1.6, or are we adding a
      NEWS entry recommending the alternative approach?

  (2) bugs/intructions-to-distributors [rlb]

      I'll handle this one -- I'll either have full fledged
      instructions by the release, or I'll include some information
      and a request for packagers to contact guile-devel before
      packaging.  This will depend on how far I get before all the
      other release critical bugs are finished.

  (3) tasks/TODO - document libtool conventions [rlb]

      Needs to be done -- will do.

  (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.

  (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.

And what else is there?  Please speak up if you can think of pre-1.6
issues that aren't addressed here so that we can evaluate them and add
entries to TODO if appropriate.

I'd like to discuss all these items and modify TODO and bugs/*
according to our conclusions as soon as possible, but bear in mind
that Thien-Thi likely won't be back until next week, and I don't want
to be too gung-ho about any of this until he's had a chance to
evaluate my two release propsals and express his concerns if any.

Thanks again.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

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

[Thien-Thi Nguyen]

   From: Rob Browning <rlb@defaultvalue.org>
   Date: Sun, 14 Apr 2002 23:39:48 -0500

     (1) bugs/optargs-bound-gone

current state "fixed: Marius Vollmer <mvo@zagadka.de>, 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

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

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

[Rob Browning]

Thien-Thi Nguyen <ttn@giblet.glug.org> writes:

> current state "fixed: Marius Vollmer <mvo@zagadka.de>, 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.

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?

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.

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.

> 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.

What's the "1mo timeout guideline"?

> 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?).

OK, will do.

> 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.

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

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD

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

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

[Thien-Thi Nguyen]

   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