ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxx>]

On Tue, Oct 06, 2009 at 12:24:18PM -0500, C de-Avillez wrote:
> 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.

Your work looks great to me also and I'm happy to approve your
membership in the Ubuntu Bug Control team.  Thanks for helping out and
welcome!

Sincerely, 
-- 
Brian Murray                                                 @ubuntu.com

Attachment: signature.asc
Description: Digital signature