ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxxxxx>]

On Thu, Jun 30, 2011 at 08:25:38AM -0400, Daniel Manrique wrote:
> Hello,
> 
> I'm writing today to request joining the Bug Control team. I believe I
> could be more helpful in the triaging process as part of Bug Control,
> both to be able to better handle bugs I'm triaging and to assist other
> triagers in reviewing and setting the desired bug parameters.
> 
> I've only been triaging bugs for a few months now, but I've tried to
> touch a wide range of bug reports to get a better feel of the process,
> as well as as much experience as possible, so as to avoid pestering
> other triagers and members of Bug Control. Their guidance in
> #ubuntu-bugs has been invaluable in my getting acquainted with the
> process and more confident in triaging bugs by myself.
> 
> Please note that, as I work within Canonical's Hardware Certification
> team, I already have some bug handling privileges, but this is subject
> to the usual conditions for team access to Bug Control, which I've been
> careful to respect.
> 
> As per the application process, here are my answers to the application
> questionnaire.
> 
> 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?
> 
> I have signed the code of conduct
> (https://launchpad.net/~roadmr/+codesofconduct) and promise to be polite
> to bug reporters even if they act rudely.
> 
> 
> 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and
> Bugs/Importance? Do you have any questions about that documentation?
> 
> I have read all four documents and still rely in them to avoid making
> mistakes while triaging. I have no questions, other than a comment, it
> being that while most info is available and documented in the wiki
> pages, sometimes it's scattered around and it can be a bit hard to have
> an overview of everything that's needed to work on triaging, I think
> something like the "ultimate triager's handbook" could eventually be
> helpful to reduce the amount of cross-linking between documentation, for
> people who want to read a top-to-bottom document to get acquainted with
> the process.
> 
> 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.
> 
> Mainly:
> - A core dump file, if it exists, has to be removed (CoreDump.gz).
> - Stack trace attachments, which are text files produced by the
> retracing service from the core dump, need to be scanned for potentially
> sensitive information such as passwords and banking information.
> - I ran into a case where ubiquity --debug puts passwords in the debug
> log, and now know to also check ubiquity logs for this information. This
> is not automatic though, the user has to specifically enable debugging
> for this to happen, so it's not as common as the core dump and trace files.

Actually, the apport hook for ubiquity will just add the file (the
ubiquity debug log) if it exists and call it UbiquityDebug.  It might
be worth reviewing all the ubiquity bug reports with this attachment
name and doing something about them.  Additionally, there is an Oneiric
work item to always run ubiquity in debug (before the final release) and
filter out the password.

--
Brian Murray

Attachment: signature.asc
Description: Digital signature