ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxx>]

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

Attachment: signature.asc
Description: Digital signature