timeless wrote: > 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?
http://bugs.opensolaris.org/view_bug.do?bug_id=6253008 Studio 10 x86 cc with -fast option is less fast than without -fast deemed too risky to fix in Studio 11, but is marked as "Fix In Progress" for Studio 12. In this case, it was too risky because of the point in the development cycle when it was discovered. ... >> Verification Not Applicable >> Verification Not Needed >> Needs Verification > > Personally, I'd use flags for this, you can presumably use states. Agreed. >> 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. It's a transient state, not a final state. >> 10-Fix Delivered >> Verified >> Unverified >> Needs Verification > >> Verification Not Applicable >> Verification Not Needed > > Why/How are these different? Typically, Verification occurs when a customer verifies that the binary fix / IDR does actually resolve the problem. At that point the bug can be marked as Verified. I don't know of too many instances where "needs verification" has been selected - my experience is that if the RE can verify the fix, and the customer has verified the fix, then there's no further verification work needed. Perhaps if a fix was quite risky it would be good to mark the bug with "needs verification." >> 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? Don't go there, it's too painful. >>> 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). That's all well and good, but what about the case where a really, really old bug against a product that has been EOL'd is still hanging around? I came across a number of those quite recently and very quickly came to the conclusion that "closed will not fix" was the most appropriate final state. For those products, it's been a long time since you could purchase the hardware, and it's also been a very long time since any active sustaining has been done. Code rots, unfortunately. > 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? owned vs not owned priority accepted vs fix understood + .... time since issue logged number of escalations or service records James C. McPherson -- Senior Kernel Software Engineer, Solaris Sun Microsystems _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
