On 10/17/07, James Carlson <[EMAIL PROTECTED]> wrote:
> 4-Defer
personally, I wouldn't do this. I understand your later points.
> Too Risky to Fix
from my perspective, Too Risky to Fix is a WONTFIX, not a DEFER.
Can someone point to an example where a bug entered this state and
left it and eventually reached a fixed state?
> Code Freeze
this seems useless, which code freeze, wouldn't targetmilestone:
{afer_x} or blocked: code_freeze_bug make more sense?
The process you have seems over-engineered and clearly relies on a
very extensive QA team. I'm used to organizations that are starved for
QA engineers. Can we just steal 2/3 of your QA engineers for the next
5 years. You could streamline some resolutions and I could ship some
less sucky projects in the interim.
> No Resource Available
keyword: helpwanted.
If someone volunteers to work on the project, why should they have to
change its state.
No Resource Available is merely a statement from one management team.
What if there are twenty possible teams and 3 want to say they don't
have resources and 2 want to say they do. I don't see why this belongs
in a bug tracker as a state. It's mixing team management with bugs.
> Future Project
targetmilestone: future (or better, stick a year into the thing if you
have one).
> Verification Not Applicable
> Verification Not Needed
> Needs Verification
Personally, I'd use flags for this, you can presumably use states.
> 9-Fix Failed
I don't understand this.Why is it a state?
Minus the patch and send the bug back to some other state.
> 10-Fix Delivered
> Verified
> Unverified
> Needs Verification
> Verification Not Applicable
> Verification Not Needed
Why/How are these different?
> 11-Closed
> Verified
> Duplicate
> Unverified
> Not a Defect
> Will Not Fix
> Not Reproducible
>
> (Yes, the number really is a part of the state name. ;-})
I'm assuming your product sorted alphabetically and you needed the numbers?
> > deferred is typically just stuck as Target Milestone: Future.
>
> Yes; you'd think. Some folks seem to think that a lot more detail is
> needed here to distinguish "not something owning group wants to do"
> from "no resources [people] available right now" and those two from
> other allied states.
>
> No, I don't know why there's fuss about this, but there is, and many
> folks who don't like the "defer" states will slam bugs closed
> (inappropriately, in my opinion) as "closed / will not fix," which
> just corrupts the database.
I'd rather you encourage people to orphan bugs they aren't working on
(assignee: [EMAIL PROTECTED] or nobody@ or whatever).
I suppose that properly using a Defer state is better than using a
Closed state, but I'd argue that based on the amount of effort to
resurrect, it isn't. And I'm more interested in the barrier to entry
than some bean counting system (and you can count unassigned or
keyworded beans just as well as other beans. Although I suppose if you
really want to count these beans at the same time as the others,
you're stuck using the extra state.
Out of curiosity, which beans do people count? i.e., when managers
make tables comparing numbers, which numbers do they collect and
compare?
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
