ubuntu-bugcontrol team mailing list archive

[C de-Avillez <hggdh2@xxxxxxxxxx>]

On Tue, 2009-10-06 at 01:18 -0500, Marc Randolph wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Howdy all,

Howdy, and thank you for your interest in helping.

> 
> Here are my responses for the bug control membership application:

<snip/>

> > 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and
>>  Bugs/Importance? Do you have any questions about that documentation?
> 
> Yes, I have read those pages. I am never afraid to ask questions, and
> I error on the side of caution (and do nothing) rather than cause
> potential disruptions.
> I do have a question on one topic: Assigning importance is probably a
> triagers most important job since it sets expectations and indicates
> the understood priority to users, maintainers, and developers.
> But I find it sometimes difficult to assign an importance:
> A. Especially when the ticket it is incomplete, or
> B. When the bug contains enough information to be "confirmed", or
> maybe even "triaged" (if a patch is provided), but I am not familar
> enough with that particular project to understand how severe the
> problem is.
> 
> In Case A, I'm not too worried, because if a bug is truely incomplete,
> then there is likely not information to accurately assign an
> importance.

This is a sane approach, I agree. Some groups set a default Importance
of Medium to all new bugs, and adjust as needed as the bug progresses.

> But in case B, is it suggested to leave the bug untouched (don't
> change the status or importance), or change just the status, or change
> the status AND make an educated guess on importance (on the assumption
> that if it is wrong, someone else will see it and change it)?

This is a good point, and one difficult to give a definite answer ;-).
But, of course, I will try (I never leave aside a chance like this).

First of all, you have to keep in mind the official definitions for
Importance -- https://wiki.ubuntu.com/Bugs/Importance. One important
point is we are free to *estimate* the potential impact. Of course, as
time goes by, our estimates will usually get better -- we learn more,
and more, about the specific package and Ubuntu/GNU/Linux. Hopefully.
But, since we are expected to estimate, it is also implied that we may
estimate *wrong*. Of course, if you get it wrong once in a while is
rather different than if you get it wrong most of the times. Bug-control
is expected to get it right most of the times.

It may also happen that, as time (and work on the bug) goes by, we learn
more about the particular issue, and may decide the (currently set)
Importance does not reflect our (now updated) understanding -- and we
are free to reset the Importance to a new value. Any such changes -- in
fact, *all* changes -- in Status and Importance should be explained in a
comment.

Now, the most importance difference between a common triager and a
Bug-control member the the ability to set the Importance (OK, and set
the Triaged status). Apart from that, a bug-controller is pretty much
identical to a non-bug-controller in capabilities. As such, we *do*
expect you will be able to set an Importance. This is why we ask
candidates to provide their best bet on what would be the bug's
importance.

Adding it all up: as a member of Bug-control you *are* expected to give
your best bet on the Importance. If it ends up being wrong, someone will
indeed reset it, and explain why.


> > 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.
> 
> First thing is to remove core dumps since they frequently contain
> sensitive user data.  user-id's or account numbers, passwords, and
> other (even physical location data) can also show up and should be
> stripped out.

Additionally, you should look at backtraces, stacktraces, etc. A 'bt
full', or 'thread apply all bt full', may contain private data. If you
find them, then you have two options:
1. sanitise the backtraces, by manually taking out any private data.
This means downloading the traces, editing/redacting them, uploading the
redacted trace, and deleting the original one.
2. Leave the bug private.

I have been working on a sanitiser for backtraces for a while (well, I
*was* working on it, then I got busy earning a life, but I am returning
to it now). Hopefully, when I am done, we will be able to automate the
clean-up process. Meanwhile, it is a purely manual process.

> > #4 Is there a particular package or group of packages that you
>>  are interested in helping out with?
> 
> I'm actually here at the suggestion of superm1 (Mario Limonciello),
> the maintainer of many mythtv related packages.  My first and main
> focus will be on the myth related projects under his supervision.  As
> time allows, I will be happy to help out on other projects where I can
> understand enough to actually be helpful (ref: case 2.B above).

Good enough, and I am sure Mario will be more than happy with your help.

> > #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.launchpad.net/bugs/436792 - High.  If you can read around
> the lengthy parallel (and off-topic) discussion regarding obtaining
> the current version, I feel this was high because it doesn't work
> after install, but can be worked around if the user is knowledgable
> enough.

Good triage work -- and I particularly liked the fact you accepted you
were wrong at one point. I also agree with the High importance.

> 
> https://bugs.launchpad.net/bugs/440342: Low because it is cosmetic.
> Was originally thought to be an upstream bug, so I forwarded the bug
> on, but it turns out it was was a Mythbuntu theme issue.  I marked it
> as triaged since the upstream provided the answer and also assigned it
> to the theme developer since he is actively working the issue
> (confirmed via IRC).

Agreed. One single point: it is usually not a good idea to assign bugs
to other people. Of course, this is a moot point *here*, since you had
already checked with the assignee. You preempted my observation above
nicely ;-)

> https://bugs.launchpad.net/bugs/440807: Critical - project was broken
> not only on nightly PPA, but also in Karmic on packages.ubuntu.com,
> where it is more accessable by inexperienced users, so therefore be
> resolved quickly.

No comments. Acceptable setting of Importance.

> https://bugs.launchpad.net/bugs/429089: Medium - there appears to be
> work-arounds for this non-major feature if the user is knowledgable
> enough.  I developed and submitted a patch upstream, which I am in the
> process of re-working.

This is one case where you could assign the bug to yourself, since you
are actively working on the resolution.

It might be a good idea to provide the shell wrapper script as a bypass.
It would also be good to rephrase the description as noted in
https://wiki.ubuntu.com/Bugs/Description. 

Good work.

> https://bugs.launchpad.net/bugs/397194: Medium - easy work-around for
> a very commonly used feature

Not much to comment here ;-)

> I welcome any critism of other bugs I've touched (it's impossible to
> make me upset, so fire away!).

Well, there is not much to be critical of, here. Generically, good work.

The only thing I am not sure of -- and I will defer to the bugmeisters
-- is why you need bug-control for Mythbuntu.

But your work more than warrants membership to Bug-control. 

+1.

> Best regards,

Cheers, and thank you for helping. We appreciate.

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