ubuntu-bugcontrol team mailing list archive

["Null Ack" <nullack@xxxxxxxxx>]

Thanks very much guys :)

Andreas, with your request for other examples here is a bug that I
have been triaging as part of my work on Intrepid:

https://bugs.launchpad.net/ubuntu/+bug/264571

Unlike some other examples, I didn't start this bug, cannot replicate
it and am actively triaging the issue with the bug reporter.

Here's another one that I didn't start. I did not agree with a
previous comment about ignoring the EULA screen and I explained why
reasons for it. When Mark Shuttleworth came into the bug and asked for
suggestions about what could possibly be done, I responded with mine
which he seemed pleased with. It's at:

https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/269656

On the issue with not confirming your own bugs:

* The documentation specifically states:

When you have a complete report, and there is enough information to
debug the program, you can confirm the report. How do you know there
is enough information? Here are some example criteria, ANY of which is
sufficient:

    * Is there a patch that claims to fix the bug?
    * Are there sufficient log files and crash dumps, as outlined in
DebuggingProcedures?
    * Can you reproduce the bug yourself?
    * Does another distribution have a complete and confirmed bug?
    * Does the upstream author have a complete and confirmed bug?

* Its not mentioned in the dos and donts of best practices -
https://wiki.ubuntu.com/Bugs/BestPractices
* The core issue about moving to confirmed is said to be "is there
enough information" as shown at
https://wiki.ubuntu.com/Bugs/HowToTriage/Charts

Please understand I'm not trying to be a smarty pants with this folks
:) Process compliance is important and Im committed to doing processes
in compliance. When I think a process should be improved, I'll stick
to the existing process and present my case about how to improve it.
In this case, I dont see the policy of not confirming your own bugs in
the process and I think such an idea is not best practice. I genuinely
think it is better to be able to confirm your own bugs because:

1. It doesnt matter if only one machine can consistently reproduce the
problem, its still a bug.
2. On a practical level, having to find someone else to replicate it
is often time consuming and it slows down getting the bug upstream or
onto Ubuntu devs.
3. If all the information is needed about the bug having one more or a
hundred more people say they have the issue only adds to an
approximation of how many people might have the bug not the fact the
bug exists.

In my humble opinion the existing process documentation is correct in
the criteria for confirming bugs in that the prime outcome for that
status is, is their enough information.

Thanks very much :)