ubuntu-bugcontrol team mailing list archive

[HggdH <hggdh2@xxxxxxxxx>]

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.
> 
> Thanks very much :)

You are welcome. 

Although not needed anymore (two already voted positively), here is my
position: application accepted. +1.

..hggdh.. 

[1] hum. we bug-controllers are not quite equal under the law... we have
more access...

Attachment: signature.asc
Description: This is a digitally signed message part