Status: Resolved Later

[Kevin Benton]

Yes, I agree.  The challenge is that part of my job is to write software to
track status so I can determine how much time was spent on fixing a bug.  It
seems to me that the place for that which makes the most sense is in the
status field rather than pulling a combination of fields together.

> -----Original Message-----
> From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org]
> On Behalf Of Stuart Donaldson
> Sent: Thursday, December 09, 2004 5:20 PM
> To: developers at bugzilla.org
> Subject: Re: Status: Resolved Later
> 
> Pending another bug would be blocked by another bug.
> Pending customer feedback means something else is blocking the bug. You
> still have an idea of when you want this bug fixed.
> 
> Keywords or Flags could work to "categorize" the bugs to indicate that
> the bug is waiting on customer feedback. Another option would be
> reassigning the bug to someone whos job it was to collect the customer
> feedback.
> 
> 
> Kevin Benton wrote:
> 
> > What if a bug is pending something other than a future release? What
> > if the bug is pending another bug or if the bug is pending customer
> > feedback. Should that time count against the engineer's time to
> > resolution? I agree that Target Milestone will help. I agree that bugs
> > that are postponed for another target/milestone should be in a pending
> > status. I'm adding FUTURE_RELEASE to my pending reason list.
> >
> > ------------------------------------------------------------------------
> >
> > *From:* developers-owner at bugzilla.org
> > [mailto:developers-owner at bugzilla.org] *On Behalf Of *Lee Ivy
> > *Sent:* Thursday, December 09, 2004 11:02 AM
> > *To:* developers at bugzilla.org
> > *Subject:* Re: Status: Resolved Later
> >
> > In my pre-Bugzilla days, we used the Target Milestone approach and it
> > worked well. A bug's Version showed what version the problem was found
> > in; if you didn't want to fix it right away you left it in the
> > Assigned state but set the Target Milestone for the future release
> > where you hoped (planned?) to fix it. The bug was still assigned to a
> > developer, but it was clear that bugs only needed to be fixed right
> > away if their Target Milestone matched the current release.
> >
> > I prefer this to Resolved/Remind -- as a QA guy, I think
> > Resolved/Remind sounds like a developer cop-out, "I am marking this
> > resolved but I didn't actually fix it, I just want to be reminded to
> > fix it someday in the future -- trust me!". To me, moving a bug to
> > Resolved implies a hand-off of responsibility from development to QA,
> > and that is not true for Resolved/Remind.
> >
> > /Lee Ivy
> > QA Architect
> > netZentry, Inc.
> > lee at netzentry.com <mailto:lee at netzentry.com>
> > /
> > Stuart Donaldson wrote:
> >
> > We wrestled with this, and I am sure I saw somewhere the suggestion of
> > using Target Milestones. That is the strategy we have adopted. You can
> > target this to any of the builds on the current project, or target it
> > to the next release, or set the target to deferred which means some
> > undetermined future release.
> >
> > I like the benefit of the required comments when using Resolve/Later,
> > however Later was not granular enough, and the paradigm seemed to fit
> > the milestone paradigm closer.
> >
> 
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=kevin.benton@amd.com>