Retargeting enhancements

Max Kanat-Alexander mkanat at
Thu Nov 10 20:30:44 UTC 2005

On Thu, 2005-11-10 at 20:02 +0100, Frédéric Buclin wrote:
> Several bugs have assignees who are pretty inactive, or who are active 
> but are not interested in these bugs anymore and forgot to reassign them 
> to the default assignee.

	I have several bugs that I am not *currently* working on, but I haven't
assigned them to the default assignee because I do plan to work on them.

> My suggestion is to retarget all enhancement bugs targetted 2.22 to --- 
> and let each assignee retarget them back to 2.24 if they are (still) 
> working on them (and marking the bug as ASSIGNED to make it clear).

	I tend to mark the bug as ASSIGNED at the moment I actually start
working on the bug. That's what ASSIGNED is for, in my understanding.

	I also tend to use the TM field to work out how I'd like to plan my
work. However, it's true that at this point enhancements that are
targeted at 2.22 should be fixed.

> Do you really want to triage more than 2000 open bugs?? Let's retarget 
> them to --- and don't waste your time triaging bugs targetted Future or 
> ---.

	My concern is this:

	We already have 2000 open bugs. The ones where we've set a TM are ones
that we actually want to and currently plan to fix. Setting their TM
back to "---" puts them back into the same class as all the other 2000
bugs, making it much more difficult to differentiate them.

	But yeah, to address Dave's concern, I almost never target a bug at a
release until it has an owner actually working on it. I think that's
generally a good idea. And I never set a bug to ASSIGNED until I
actually put a patch on it.

	The only exception to this that I can think of recently was the Custom
Field bugs, where I really wanted to see somebody take them for 2.22, so
I targeted them when they had no owner.

Competent, Friendly Bugzilla Services. And Everything Else, too.

More information about the developers mailing list