* Re: 1.6 release -- where I'd like us to go from here. [not found] <87g01xinhn.fsf@raven.i.defaultvalue.org> @ 2002-04-24 7:21 ` Thien-Thi Nguyen [not found] ` <E170H5X-0007XQ-00@giblet> 1 sibling, 0 replies; 3+ messages in thread From: Thien-Thi Nguyen @ 2002-04-24 7:21 UTC (permalink / raw) Cc: guile-devel, guile-user 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-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <E170H5X-0007XQ-00@giblet>]
* Re: 1.6 release -- where I'd like us to go from here. [not found] ` <E170H5X-0007XQ-00@giblet> @ 2002-04-24 14:04 ` Rob Browning [not found] ` <87d6wpkxb1.fsf@raven.i.defaultvalue.org> 1 sibling, 0 replies; 3+ messages in thread From: Rob Browning @ 2002-04-24 14:04 UTC (permalink / raw) Cc: guile-devel, guile-user 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-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <87d6wpkxb1.fsf@raven.i.defaultvalue.org>]
* Re: 1.6 release -- where I'd like us to go from here. [not found] ` <87d6wpkxb1.fsf@raven.i.defaultvalue.org> @ 2002-04-24 18:11 ` Thien-Thi Nguyen 0 siblings, 0 replies; 3+ messages in thread From: Thien-Thi Nguyen @ 2002-04-24 18:11 UTC (permalink / raw) Cc: guile-devel, guile-user 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-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-04-24 18:11 UTC | newest] Thread overview: 3+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87g01xinhn.fsf@raven.i.defaultvalue.org> 2002-04-24 7:21 ` 1.6 release -- where I'd like us to go from here Thien-Thi Nguyen [not found] ` <E170H5X-0007XQ-00@giblet> 2002-04-24 14:04 ` Rob Browning [not found] ` <87d6wpkxb1.fsf@raven.i.defaultvalue.org> 2002-04-24 18:11 ` Thien-Thi Nguyen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).