On Thu, Oct 18, 2007 at 01:34:35AM +0300, timeless wrote: > > Too Risky to Fix > > from my perspective, Too Risky to Fix is a WONTFIX, not a DEFER.
It depends. If it will always be too risky, that's correct. But sometimes it might just be too risky for the present release. Though I would argue that should really just be targetted to a different release then. > 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 Actually, engineers use these states. Quite frankly, testing teams usually just file bugs and sometimes close them as verified. Everything in between is used by engineering. > > 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. I agree, though I don't believe the keyword should be used. Any bug in the dispatched state (or its equivalent) should be considered helpwanted. An alternative would be for the initial evaluators to move the bug into some state that means "the bug is valid but no one has accepted responsibility for working on it". Historically that's Defer/No resource. As Jim pointed out, it's extremely important that such a state exist and that it be obvious to everyone how to mark bugs that belong in it. The helpwanted keyword, I think, is the wrong answer here. > > Future Project > > targetmilestone: future (or better, stick a year into the thing if you > have one). This is a bit different. I'm not sure how other groups use it, but I put bugs in this state if I have a specific project in mind that will fix the bug, and I have accepted responsibility for doing the project. I'm just not actively working on it right now. In this state, it is reasonable for someone to approach me (I should be the RE on the bug) and ask if they can fix it or what I had in mind for it. If we agree on an approach, he or she can take it over. It's not just saying "someone might want to work on it later". > 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. A lot of people here don't like it, either. It's rarely used and I guess I wouldn't miss it. Maybe someone who makes more use of it will defend it, though. > > 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). Well, we have that today, too: RE = (null). Jim didn't want to get into the politics of it, and frankly I don't either, but I think it's worth a brief explanation of the problem so that we can think about how to avoid it in a new system. Maybe more detailed deferred states are the answer, maybe it's something else. But as I said above, there has to be a single well-understood way to note that a bug is not currently being worked on. The problem in a nutshell: in Bugtraq, there is a Responsible Manager field. This field (which should not exist in our solution) is used by managers and directors to run a variety of metrics (the nature of which is neither comprehensible nor important to us). For a variety of reasons, managers find it advantageous to minimise the number of open bugs assigned to them. The most expedient way to do this is to close bugs that are "old", "stale", or to which they do not anticipate having any resources to assign. Unfortunately, this often leads to legitimate bugs being closed when in reality they should be marked Defer/No Resource or perhaps Defer/Future Project. In rare cases, the right answer is to evaluate the bug technically and conclude that it's not worth fixing (Closed/Will Not Fix). With that in mind, and recognising that there shouldn't be an RM field in our DTS, how do we make sure this doesn't happen? Managers (not just at Sun, presumably) will want to track the work their engineers are doing. But it's no longer meaningful to assign them bugs, and it's no longer their responsibility to deal with bugs that aren't actually assigned to someone they manage. Conceptually, then, this just shouldn't be a problem for us. But I still worry... > Out of curiosity, which beans do people count? i.e., when managers > make tables comparing numbers, which numbers do they collect and > compare? I don't know. I do know, based solely on observation, that 4-Defer seems to count "against" the manager in some way that 11-Closed does not. That this problem could seemingly be fixed today by using Bugtraq differently does not mean that we shouldn't be looking for ways to avoid it. Involving some of those managers and their directors here actually seems like a useful idea. They are, after all, representative of one type of consumer of this information. The metaquestion here is: how concentrated should bug status be? In Bugtraq, it's all in the State fields. Bugzilla seems to make heavier use of keywords for this, something with which I find myself uncomfortable, especially given the number of misspelled keywords in Bugtraq today. Clearly, some of the states we have make sense only in a managed development regime. Maybe they can go away. But whatever we replace them with needs to be simple and clear: I'd prefer to be able to tell just by looking at the RE/Assigned-To and State fields exactly what's happening with the bug. The fewer places one has to look (and change), the better. -- Keith M Wesolowski "Sir, we're surrounded!" FishWorks "Excellent; we can attack in any direction!" _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
