ubuntu-bugcontrol team mailing list archive

[Vishnoo <vish@xxxxxxxxxx>]

On Thu, 2010-12-30 at 10:27 +0100, njin wrote:
> -Do you promise to be polite to bug reporters even if they are rude to
> you or Ubuntu? ****yes
> -Have you signed the Ubuntu Code of Conduct? yes
> -Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and
> Bugs/Importance? ****yes

Hi,
Let me start by saying, thanks for helping with bug triage. You have
been doing a lot of work! :)

> -Do you have any questions about that documentation? ****no
> -What sensitive data should you look for in a private Apport crash
> report bug before making it public? ****every kind of private data
> (passwords, keys,or everythings can be a privacy violation if public).
> coredump.gz never has to be attached to a public report.

> -Is there a particular package or group of packages that you are
> interested in helping out with? ****Ubiquity, Debian-installer.
> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/684083

This bug was reported by you and it was triaged by Colin instead.

> reproduced looking at top ghostscript at 100% of cpu
> https://bugs.launchpad.net/ubuntu/+source/at-spi/+bug/642888
> 

You did identify the package, but the bug here was triaged by Charlie
(comment#1).

> Remembering the debugging of gpm i've decided to switch off plymouth at
> boot, hight set by chris as makes ubuntu unusable for nvidia cards
> https://bugs.launchpad.net/launchpad/+bug/692291

I think you might have quoted the Wrong bug # here?
This is not an Ubuntu package bug, this is a bug in launchpad itself.

> But why on this pc don't work and on the other works, ah it's not
> maximized....i'm the only reporter, importance set by another
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/390959

You could have just asked the reporter to run the following command:
$ apport-collect 390959

That would have collected all the info that was required , rather than
the reporter having to attach one file at a time. It would have been a
lot more easier for the reporter.
This looks like one of your earlier bugs, but We need to remember the
tools available to us.

> just following how to triage
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/480903

In this bug you did mention apport :)
But, when requesting information you changed the status from:
 incomplete -> confirmed , rather you should have left the status as
incomplete until the apport info was collected.

Luckily the reported did add info using apport.
But what if the bug reporter had not? The bug would have been marked
confirmed without any info.

> missed driver in the kernel. reporter sayd that installing drivers from
> producer site make it working.
> https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/674663

The tagging for this bug is weird and introduces custom tags.
The correct tag to be used here is `needs-upstream-testing`  and once
done it just needs to be removed. no need for any new tag.
Are you sure about the tag 'regression-update' here? There is no
indication that an update from the maverick-updates caused the bug.
It seems more like a `regression-release` since the bug was also later
re-titled. 
What would have helped was, if the reporter was asked if the problem did
not exist when he installed Ubuntu 10.10 fresh. And started happening
only after a particular update. It would narrow-down the cause of the
bug here.

for more info on tags:
<https://wiki.ubuntu.com/Bugs/Tags#Kernel%20Specific>
<https://wiki.ubuntu.com/Bugs/Tags#Regression%20specific>
<https://wiki.ubuntu.com/Kernel/Tagging>


> as john lennon sing "with a little help from my friends"
> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/668800

This one seems fine. Would have preferred info from the original
reporter though, but a triager adding the info is also good.


IMO, The list here would only be 4 bugs that you had triaged for others.
However, I'v noticed that you have been doing a lot of triaging, but the
bugs you selected are not a great list. If i had not noticed the work
you've been doing , based on the bugs listed here I would have -1'd your
application.

But, I'm pretty sure you would have a better list of bugs that *you*
have triaged for others. 
So +0 for now.

> i don't remember
> And many others
> 

Have a look at:
<https://bugs.launchpad.net/~fabiomarconi/+commentedbugs>
<https://bugs.launchpad.net/~fabiomarconi/+subscribedbugs>

Try to choose bugs where you have made less mistakes, preferable
none. :)

Have a look at the BugControl criteria:
<https://wiki.ubuntu.com/UbuntuBugControl#Evaluation%20Criteria%20and%
20Process>
And a few example applications:
<https://wiki.ubuntu.com/UbuntuBugControl#Example%20Application>

Everyone makes mistakes when starting with bug triage, but when
submitting an application for Bug Control it is better that you list the
bugs where you have done your *best* work.

If you are not able to find any bugs without mistakes, I'd suggest you
focus on the packages you are interested in(Ubiquity, Debian-installer)
and get back with a good bug list.

Looking forward for a better list of bugs.. :)

Also do mention the bug importance that you think is appropriate,
BugControl are the folks who set these, so it's kinda important that you
mention along with the bug list too . (Yes, the wiki is ambiguous, looks
like the wiki needs to be updated and more clear about this. Every
'triaged' bug,which is what we request for bugcontrol application, would
have an importance set, so adding the clause of "does not have an
importance" is a moot point. Have a look at the application examples.)


-- 
Cheers,
Vish