ubuntu-bugcontrol team mailing list archive

[Micah Gersten <micahg@xxxxxxxxxx>]

Replying inline as one message

On 08/18/2010 05:40 PM, Micheal Harker wrote:
> oops I clicked send there by accident. The reply is AFTERthe original
> message.
> 
> On 18 Aug 2010, at 23:16, Micheal Harker <
> <mailto:michealh@xxxxxxxxxxxxxx>
> <mailto:michealh@xxxxxxxxxxxxxx>michealh@xxxxxxxxxxxxxx
> <mailto:michealh@xxxxxxxxxxxxxx>> 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. I have signed the Code of Conduct and yes I will be polite
>> whenever someone my hurt me of my feelings for ubuntu. I believe
>> CONSTRUCTIVE criticism will make Ubuntu even better.

The goal is to *always* be polite *even if* one is insulted.

>> ---------------------------------
>> 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and
>> Bugs/Importance? Do you have any questions about that documentation?
>>
>> Nope, It seems pretty straight forward and I use Ubuntu on a Day so I
>> can check some bugs out then. Also, If I had any questions on the
>> matter as they arise I can ask on IRC before carrying out an action.

Well, there seems to be an issue with posting responses which we'll get
to down with the bugs.

>> ---------------------------------
>> 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.
>>
>> I defiantly heard from there that if a CoreDump.gz is attached then
>> make the report private. The file may contain sensitive information
>> but I have to subscribe myself first.

Well, stacktraces can also contain private data.

>> ---------------------------------
>> 4. Is there a particular package or group of packages
>> that you are interested in helping out with?
>>
>> Acctually no, I am a sorta what We should call "all rounder" at buy
>> reporting and answering. I try to get all the new Bugs  sorted and as
>> being as I have lots of time let's see If I can get the list down to a
>> manageable number using what the wiki page tells us :)
>> ---------------------------------
>> 5. Please list five or more bugs which you have triaged. These bugs
>> should demonstrate your understanding of the triage process and how to
>> properly handle bugs. For *each* of these bugs, please point out what
>> Importance (and reasoning) you would give it after becoming a member
>> of Ubuntu Bug Control. Please use URLs in your list of bugs. 
>>
>> Bug #616538 - I chose medium for severity and Medium was decided upon.
>> This is because some people may want to install the package but can't.

On this bug, you posted a link to the comment text instead of the actual
comment.  There seems to be an issue with the confirmed state, but I'll
bring that up in a separate mail to the list.  Is this bug in Maverick
as well which has the 2.6.35 kernel?  We normally don't support the
mainline kernel in any release.  There was talk of a Maverick kernel
being backported for Lucid for certain uses, but I haven't seen that
yet.  Why was this bug accepted?

>>
>> Big #616536 - I thought the severity should have been medium. It was
>> picked Medium I said It was because if a ubuntu use likes that
>> screensaver and has some work ing
>>

Once again you posted the link to the response instead of actually
responding.  Were you able to reproduce this in a Maverick Live CD
environment?

<snip signature, repeat text />
> Anyway Let me continue 
> 
> If the user wanted to have the screensaver but had apt running he would
> soon find out apt broke because of it. Not Good.
> 
> Bug #616581 - I decided Medium again but the bug was classified as high.
> I thought it should of been medium because It wouldn't affect the
> majority of users. But now I understand why it is high.

Yes, High is appropriate since it makes the default install unusable.

>  Bug #619532 - This bug was triaged in Ubuntu (as well as 100 paper
> cuts). I decided on Low because It could annoy people just the tiniest
> bit. But I was set to wishlist which is even better than low for this. I
> also understand why It was wishlist material.

Wow, this bug is a doozy, there's a list of issues:
1.  We don't know where the user is trying to change the password.  That
might affect where the bug should have been assigned.
2.  The bug was upstreamed without a link back to Launchpad bug.
3.  The bug description was copied and pasted upstream without checking
to make sure it made sense.  This was noted by one of the Debian
Maintainers (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593513#18)
4.  I was not given a status for this bug.  I was just asked that it
should be "Triaged".  (Yes I should've asked, but I was busy).
5.  The triager created an atmosphere of hurry in the channel that this
needed to be completed immediately.  This led to issues 1-3 not being
properly addressed by the Bug Control members that were helping.  (We're
at fault too in this case).
Triage requires a cool head and calm to insure that the proper actions
are taken.  This keeps us from wasting the time of Ubuntu developers,
upstream developers, and reporters.

> Bug #616446 - It was suggested at low and It had gotten the Low status I
> decided on Low because It wasn't really Wishlist nor Important It was
> just a general issue that didn't need to have the same priority as other
> big massive bugs because It Network manager was perfectly fine but It
> just needed that tweak. It was fixed in a later update.

This bug is Incomplete which means that it has not been triaged to
completion in one way or another.  There's really not enough information
to tell what the importance should be at this time.  If it's
reproducible, it might be medium since the package might be installable.

The main difference between Bug Squad and Bug Control is being able to
determine when a bug has enough information for Developers (to set
Triaged) and set the Importance.  While you do have some understanding
of the Importance, I do not believe that you understand what constitutes
a bug with enough information yet.  Furthermore, while you are very
eager to help which is a good thing,  I think you need to slow down and
ask more questions.  I would suggest getting a mentor and trying to
specialize in one or several areas where you have a good understanding
of how the packages in question work so that you can easily test
reproducible steps and know what's necessary for triage.

Given mentoring and some time, I think you can be a great help, but at
the moment I have to give your application a -1.

Micah