ubuntu-bugcontrol team mailing list archive

[Alberto Salvia Novella <es20490446e@xxxxxxxxx>]

Gunnar Hjalmarsson:
> I agree that triagers should check out confirmed bugs. But new ones are also
> motivated to look at, since many of them are easily triagable.

I see what you mean: there are many bugs that are affecting someone else 
but its status is "new".

The point here is most new bugs doesn't fall into this, since they need 
someone to confirm them first.

Although you can confirm bugs while triaging, they are really two 
separated processes; where triaging always depends on confirming first:

 [New bugs] --> (Testing process) -->
 [Confirmed bugs] --> (Triaging process) -->
 [Triaged bugs] --> (Fixing process) -->

So the idea behind having a list of confirmed bugs only is to have a 
more coherent work-flow, where when you are testing you are testing and 
when you are triaging you are triaging.


Alberto Salvia Novella:
> Moreover, what is the point of confirming bug reports one by one?

Gunnar Hjalmarsson:
> Not sure what you mean. If you think a bug is ready for the
> developers, you mark it "triaged", don't you?

What I mean is if a bug has a status of new you will have to confirm it 
before triaging it. If it is confirmed, you can go directly to the triaging.

So why merging processes? Specially when confirmation is done itself 
during testing and day by day system usage.


Alberto Salvia Novella:
> If the bug is somehow relevant, wouldn't it be happening to at least
> two people in the world while testing the software? Then why not
> spending
> that time rather in finding bugs than in reading tons of invalid
> reports?

Gunnar Hjalmarsson:
> I don't think there is an absolute truth here.

There isn't. What I am suggesting is that perhaps it is worthless to be 
looking through, lets say, fifty new reports for finding one that is 
about a relevant bug; when having a list of already confirmed bugs where 
nearly all of them are fixable for sure.


Summarizing: looking through new reports is relevant when hunting bugs 
in the system, and irrelevant most of the time when making reports ready 
to be worked on by a developer.

Regards.