On Mon, Sep 15, 2008 at 09:18:47PM -0500, HggdH wrote: > On Tue, 2008-09-16 at 11:59 +1000, Null Ack wrote: > (snip) > > > > https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/269656 > > Correct tentative identification, correct actions. > > > > > 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 > > No, it is not mentioned there. Unfortunately, it seems now... but it is > here: https://wiki.ubuntu.com/Bugs/Status. > > > > * 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. > > Although when an issue is clear enough we might even go and confirm our > own bugs, this is *generically* dangerous. It is, certainly, possible > for someone with enough knowledge of the affected package. But... common > experience has shown that this is usually *NOT* the norm with the casual > reporter. > > And this then would create a caste: IF you are good on this, THEN you > can confirm your own bugs; OTHERWISE do not touch it. Very soon we would > be required to provide a "good enough" badge to distinguish the > reporters... [1] > > Also, even very technical folks mess up. > > So the rule: you should not do it. It does not matter if you are good or > not, do not confirm your own bugs. This makes everybody equal under the > yoke of the law, and provides a chance for somebody else (a > theoretically independent party) to accept (i.e., confirm) or not the > report. I personally agree with it, since I would rather have somebody > else confirm what I found.
I agree with hggdh here, there are some very rare exceptions as to when it _might_ be okay to confirm your own bug but the standard rule should be and is not to confirm your own bug reports. -- Brian Murray @ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
