Status: Resolved Later

[Lee Ivy]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bugzilla.org/pipermail/developers/attachments/20041209/ceae29ae/attachment.html>