← Back to team overview

ubuntu-bugcontrol team mailing list archive

Re: Application to join the Bug Control team

 

Thanks Louis,

I think the answers generally make sense. Some comments inline:


On Fri, Jul 19, 2013 at 3:39 AM, Louis Bouchard <
louis.bouchard@xxxxxxxxxxxxx> wrote:

> Hello,
>
> Le 18/07/2013 17:22, Matthew Fischer a écrit :
> > Can you explain the reasoning behind the Importance that you set these
> > bugs to or whether you agree with that someone else set them to?
> >
> >
> >     LVM cluster command failure :
> >     https://bugs.launchpad.net/ubuntu/precise/+source/lvm2/+bug/833368
> >
> >     - Helped out document and process the SRU. Reproduced the problem &
> >     confirmed the fix.
> >      * Assigned myself to the issue
> >      * Updated description for SRU
> >      * Invalidated unneeded/irrelevant tasks
> >
>
> For this bug, importance was set by the sponsor who reworked the
> proposed patch. The clustered LVM functionality was broken and did
> provoke dysfunctional behaviour upon reboot : impossibility to import
> clustered VG which could cause reboot issues
>
> >     Samba Win95 printing :
> >     https://bugs.launchpad.net/ubuntu/+source/samba/+bug/967410
> >
> >     - Reproduced the issue, identified the upstream fix & lead the SRU
> >     process to published fix.
> >      * Assigned myself
> >      * Adjusted Status
> >      * Updated description with SRU template
> >
>
> Here, the only place where I did change the importance was for the
> Quantal task where the fix had already been implemented. For the other
> tasks, the fact that it affected more than 50 people and did break an
> interoperability function that worked well in the previous LTS release
> explains the "High" Importance.
>
> >     debootstrap reports corrupted files :
> >     https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/1023069
> >
> >     - Reproduced the issue, identified the upstream fix & lead the SRU
> >     process to published fix.
> >      * Took over ownership
> >      * Updated description with SRU template
> >      * Understood that "Fix Released" was not when the fix had been
> uploaded
> >
>
> Again here, Importance was set to "High" as the bug did break a very
> basic functionality for an LTS release (unattended install using PXE).
>
> I did not set it myself; it was done after discussion with Adam Stokes.
>
> >     kernel thread hang on iscsi disconnect :
> >     https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1056746
> >
> >     - Reproduced the issue, identified the upstream fix & lead the SRU
> >     process to published fix.
> >      * Took over ownership
> >      * Idendified upstream kernel commit fixing the issue
> >      * Adapted subject to match kernel context
> >      * Requested new bug tasks to someone with privs
> >
>
> With this bug, Importance was set by kernel team members after
> discussion that outlined the fact that this bug did break reboots when
> iSCSI was being used. The resulting situation was a complete kernel
> hang. It did definitively break accessibility of the server upon reboot.
>

I think even Critical fits here:

   - Renders the system temporarily or permanently unusable



>
> >     dante cannot use tmpdir :
> >     https://bugs.launchpad.net/duplicity/+bug/1005901
> >
> >     - Reproduced the issue, identified the upstream fix & lead the SRU
> >     process to published fix.
> >      * Requested appropriate tasks to someone with privs
> >      * Kept status in sync with bug fix
> >
>
> For this later case, Importance was set to Medium as the impact is on a
> non-core application and only happens in specific contexts. Though an
> advertised functionality did not work, the context of it happening
> (limited space in /tmp, specific restore mode) did not justify for  a
> higher importance.
>


I think Low makes sense here:

   - Bugs that have a moderate impact on a non-core application




>
> I hope that those answers are satisfactory.
>
> Kind regards,
>
> ..Louis
>
> --
> Louis Bouchard
> Backline Support Analyst
> Canonical Ltd
> Ubuntu support: http://canonical.com/support
>

Follow ups

References