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 :) _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
