ubuntu-bugcontrol team mailing list archive
-
ubuntu-bugcontrol team
-
Mailing list archive
-
Message #03907
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