REMIND and LATER considered harmful [was Re: RESOLVED]

[Benton, Kevin]

Just thinking out loud...

> On 7/12/05, Luis Villa <luis.villa at gmail.com> wrote:
> > On 7/12/05, Gervase Markham <gerv at mozilla.org> wrote:
> > > Benton, Kevin wrote:
> > > > EWWW!  Since you brought it up, I think this RESOLVED/LATER and
> > > > RESOLVED/... for things that really don't resolve the issue
should
> be
> > > > changed to something that tells the real story, especially for
> process
> > > > monitoring software.
> > >
> > > I completely agree about REMIND and LATER, but I do think that
MOVED
> is
> > > a resolution, because it means that no further work should be done
on
> > > this bug in this place.
> >
> > Thirded. Does this mean we can get a patch for bug 13534 into 2.20?
> 
> Note that I'm looking at this right now, but... guh, I've never
> touched checksetup.pl, and I suddenly have the nagging feeling that
> getting this Right in the upgrade case will be hard. (It is easy in
> the clean install case, I can likely throw up some patches to do that
> before lunch, including for docs.)

Thanks :)  After any such changes were made, it seems to me that we'd
also need to have a pending reason along with a date the status is
expected to change from PENDING to ASSIGNED.

> P.S. The reason I get pissy about this is that I believe firmly that
> software should be useful out of the box, and we've shipped now for
> six years with defaults that we acknowledge are deeply broken. It
> makes it harder to recommend bugzilla when I've had very smart people
> come to me and say 'well, I just installed bugzilla like you told me,
> and there are these weird resolutions- but I know there must be a
> reason for them, or else why would they be in bugzilla? I guess we'll
> just figure out how to use them.'

I agree.  The challenge is - producing useful software first, then
tuning it.  I don't have a problem with how REMIND and LATER were
implemented at the time and I'm sure the person who developed it thought
that having a "PENDING" status would also be nice, but they probably
weren't ready to code it at the time.

I think, if we have PENDING, we could easily reuse the resolution field
(assuming it gets converted to an index rather than an enum - which may
have already happened), changing its name to status_info.  With a
PENDING status, I would hope we'd also implement comentonpending in the
configuration section as putting a status into PENDING requires more
information.  I'd also hope we'd somehow implement (maybe in a second
phase) automatic status changes to take a bug out of PENDING after a
pre-defined period.

In my view, there are two types of transitions that could be made to
PENDING.  First, is from NEW/ASSIGNED to PENDING where an engineer has
acknowledged the bug but is not able to (for whatever reason) handle the
issue immediately.  The other transition into a PENDING status is when
QA is similarly awaiting information and unable to handle the issue
immediately.  From my perspective, PENDING is not an excuse to stop the
clock.  PENDING is meant only for situations where the bug owner is
waiting on something outside his/her control and not able to move
forward until that other piece is resolved.

In my mind, a bug could be pending:

Customer or Third Party Feedback
Customer or Third Party Action
Review
Approval
Another Bug (in which case it should reference the bug or bugs -
depends_on)
Other (catch-all for things I haven't thought of - would need to be
policed, however).

---
Kevin Benton
Perl/Bugzilla Developer
Advanced Micro Devices
 
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information.  Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices.  This
communication is for the intended recipient(s) only.  If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.