← Back to team overview

ubuntu-bugcontrol team mailing list archive

Re: Application for bug-control

 

On Mon, Jun 01, 2009 at 09:14:02PM -0500, Paul Larson wrote:
> 1. Do you promise to be polite to bug reporters even if they are rude to
> you or Ubuntu? Have you signed the Ubuntu Code of Conduct?
> Yes, and yes.
> 
> 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and
> Bugs/Importance? Do you have any questions about that documentation?
> Yes, I've read all of those.  I don't have any unanswered questions at
> this time, but I certainly know that I can ask on the mailing lists, or
> on irc when I have more questions.
> 
> 3. What sensitive data should you look for in a private Apport crash
> report bug before making it public? See Bugs/HowToTriage for more
> information.
> Passwords, bank accounts (or anything looking like that), and CSS keys
> are specifically mentioned, but those are only a few examples.  If it
> does not contain any private data, and the stack trace looks ok, then
> the CoreDump.gz should also be removed before marking it public.  Also,
> I've heard some debate over whether usernames and hostnames should be
> considered private data.  I'd love to hear if there is a consensus on
> that, but in the meantime, best to err on the side of caution.
> 
> 4. Is there a particular package or group of packages that you are
> interested in helping out with?
> Yes, since I also work on mobile projects, I have an interest in
> triaging bugs related to mobile (UNR, ARM, netbook-launcher,
> desktop-switcher, maximus, etc).  However, for historical reasons, I
> also have a great deal of interest in the kernel.  So if I have spare
> time, I'd like to help out there as well.  I'm not opposed to triaging
> in any area though.
> 
> 5. Please list of five or more bugs which you have triaged. These bugs
> should demonstrate your understanding of the triage process and how to
> properly handle bugs. If there is a bug in your list that does not have
> an importance indicate what importance you would give it after becoming
> a member of Ubuntu Bug Control. Please use urls in your list of bugs.
> 
> https://bugs.edge.launchpad.net/netbook-remix/+bug/381336
> I would mark this one a high, because it has a severe impact on what
> will probably be a small number of users.  Triaging is still in
> progress, perhaps after getting a stack trace we will be able to
> determine if it is a dup of another bug out there, but still needs more
> information.

You've done a great job working with the bug reporter here and I
appreciate your patience.  I'm nitpicking here but I would actually put
the bug number in the apport-collect command so it is easier for people
to copy and paste.  I agree with an importance of high.
 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/286935
> It has been a long time in invalid state with no response.  I sent a
> friendly reminder requesting the information provided, check again in 2
> weeks to see if there is no response still, and if not, mark it invalid.
> Importance: Medium - it is a problem with a non-essential hardware component

This is fine but not particularly interesting.  I agree with a Medium
importance.

> https://bugs.edge.launchpad.net/ubuntu/+bug/372461
> I had to just move this one to Ubuntu, because it really doesn't affect
> a package (and bugs are not supposed to go in UNR).  I also confirmed
> it, linked it to the blueprint that was recently discussed, and asked
> that it be changed to wishlist

This looks great to me.  It's my personal opinion that these types of
bug reports (ones that relate to the distribution as whole) should be
about ubuntu-meta.  This is primarily because it is currently
challenging to find bugs in "Ubuntu", the bugs with no package, due to
the large volume of them.  By having them filed about the ubuntu-meta
package we can easily find them in the future.

> https://bugs.edge.launchpad.net/f-spot/+bug/290654
> I confirmed the bug, marked it confirmed, and opened the upstream task
> and linked to the bug.
> Importance: Medium (this was already set when I started looking at it,
> but seems good to me, since it crashes the application with steps that
> are not that unusual)

This looks great also, thanks for taking the time to open the upstream
bug task.
 
> https://bugs.launchpad.net/linux/+bug/368809
> Importance: Low, as I feel this is probably a relatively uncommon
> configuration, and is not something that seems to be a severe impact

It looks like you added the upstream bug watch for Linux which is great.
However, the bug still has a cpufreqd task while it really should be
linux task.  Additionally, if a linux bug has an git commit from
upstream it should also be tagged 'cherry-pick'[0].  I think Medium
might be more appropriate since this seems to be a regression.

Overall, your application looks great and I am happy to approve your
membership in the Ubuntu Bug Control team.

[0] https://wiki.ubuntu.com/Bugs/Tags#Kernel%20Specific

Sincerely, 
-- 
Brian Murray                                                 @ubuntu.com

Attachment: signature.asc
Description: Digital signature


References