| Thread Previous • Date Previous • Date Next • Thread Next |
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.htmlAs 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.
| Thread Previous • Date Previous • Date Next • Thread Next |
