ubuntu-bugcontrol team mailing list archive

[Mathew Hodson <mathew.hodson@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15-08-12 03:06 PM, Brian Murray wrote:
> On Tue, Aug 11, 2015 at 05:11:16PM -0400, Mathew Hodson wrote:
>> I'm Mathew Hodson (mathew-hodson), and I have be helping out with
>> Ubuntu bugs in my spare time for about a year. I would like to
>> join the Bug Control team.
> 
> Great! I've seen your work and was hoping that you would apply.
> 
>> "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 promise to always be polite, and I have signed the Ubuntu Code
>> of Conduct.
>> 
>> "Have you read Bugs/Triage, Bugs/Assignment, Bugs/Status and 
>> Bugs/Importance? Do you have any questions about that
>> documentation?"
>> 
>> I have read them, and I don't have any questions at this time.
>> 
>> "What sensitive data should you look for in a private Apport
>> crash report bug before making it public? See Bugs/Triage for
>> more information."
>> 
>> Remove Coredump.gz before making the bug public, and check the
>> stack traces for financial information, login credentials, or
>> security keys.
>> 
>> "Is there a particular package or group of packages that you are 
>> interested in helping out with?"
>> 
>> I am particularly interested in bugs that would be a good
>> candidate for or are going through the SRU process.
> 
> How do you go about determining which bug reports are good
> candidates for a Stable Release Update? More specifically how do
> you find these types of bugs in Launchpad.

If I find bugs that already have a Trusty task, I will add the SRU
template so that they are more likely to get picked up. I also keep an
eye out for bugs with a lot of heat or that I have seen complaints
about on other websites.

Mostly I check
http://people.canonical.com/~ubuntu-archive/pending-sru.html and make
sure the tags and status are correct and try to verify if I am able.

>> Bugs I have worked on:
>> 
>> https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1358154
>>
>> 
Confirmed that the fix was incorrect and identified the proper fix.
>> Importance Low because it is not essential for use of the
>> application.
> 
> Given that the bug is not in fact fixed, the status of the task
> should not be Fixed Released. Additionally, given that the intent
> was to fix the bug in Vivid, there should probably be a task for
> Vivid. Otherwise, your work here looks good.
> 
>> https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1296218 
>> Confirmed issue still existed on Trusty and reproduced with log. 
>> Importance Medium because it has a severe impact on a non-core
>> application.
> 
> This looks good to me and I've reopened the task. I forget if there
> are permissions associated with reopening a bug task - is changing
> a bug task away from Fix Released not something that you can do?

Thanks for fixing the status on those bugs. I mentioned them in
#ubuntu-bugs, but that channel doesn't seem to get a lot of activity.
Only members can move from Won't Fix or Fix Released, and only members
can add a task for a specific release.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVy8O8AAoJEEUTBuC2oiinfJQH/1jWA1WfjXbu5C3qZyCMeP5e
FRYoPN7dIHUm5MLIUnJukN+S4B7syr7n1Eho4hEeCgwLzrCHhYqQAjxdMTg43hTj
ke0CLB0v98TNOZ5oooJ+IL4Qrb0IXAEXLDFPdNdEiFIpQt/F3qTfGd8bphcNgDMQ
rhPJFLs9C/srMQVyyVRTV2yVuTSx7fKNUqR5DkSE6G0BqlZdex7GqZxBwtxW4QV2
KeZBEVjUisbwxeEPuZYETY3DggeIS9qyT1pZi4b0GX8mn681PO07IVMATqK33vlN
QuSXomafuTYZxijM+79BUP2kSTTjmpLy2N5muKiTWgTES6UpMHXt9nGea/5FQVo=
=9XKn
-----END PGP SIGNATURE-----