On 07/19/2014 07:59 AM, Alberto Salvia Novella wrote:
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.
https://lists.launchpad.net/ubuntu-bugcontrol/msg04084.html
As discussed before, some 'New' bugs can go directly to triaged, such as
requests for packaging/upgrading, or bugs which have an obvious cause
(like a proprietary driver not building on a new kernel). While your "3
step" model above is a nice suggestion, not everyone finds their work
flow fits it well.
To touch on what I was saying before, a list of 'Confirmed' bugs will
probably be diluted, since users may mistakenly confirm similar bugs and
some bugs are automatically confirmed by a bot(s) when only one person
experiences them, so they're not necessarily reproducible. In other
words, I don't personally believe that a list of 'Confirmed' bugs has
value much greater than looking through 'New' bugs. In fact, looking
through very recent bugs has more value to me, since they're less likely
to already be fixed upstream, and one can focus on the most recent
version or packaging change that a package received as the probable
culprits.
_______________________________________________
Mailing list: https://launchpad.net/~ubuntu-bugcontrol
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
More help : https://help.launchpad.net/ListHelp
