Kernel Bug Migration
leann.ogasawara at canonical.com
Wed Jun 11 16:51:45 UTC 2008
On Wed, 2008-06-11 at 17:02 +0100, Tim Gardner wrote:
> Leann Ogasawara wrote:
> > On Tue, 2008-06-10 at 10:20 +0100, Tim Gardner wrote:
> > [snip]
> >> If I understand your algorithm correctly, you plan to migrate unpopular,
> >> little noticed bugs from older releases. I'm wondering, why bother?
> > I'm not sure I'd classify them as "unpopular" but I definitely agree
> > they go unnoticed. That's why I'd at least like them to test with the
> > most recent kernel to verify if their bug has been fixed or not. If
> > not, it's likely the issue may exist upstream I imagine so this may be a
> > scenario to forward bugs upstream.
> I meant unpopular in the sense that your algorithm requires that this
> class of bugs have fewer then 10 comments.
Ah yes, the <= 10 subscribers. I think I'm going to get rid of this
criteria. I'll manually take a peek at the ones with a high subscriber
count and we'll clean up the rest automatically.
> > For 2.6.15 bugs I proposed a slightly different process just because it
> > was an LTS release. But I'd be fine with using the same procedure above
> > that I'd use with the other non-LTS kernels.
> I can't think of a good reason not to use the same algorithm for Dapper.
> My support focus is primarily on server and CVE issues. Desktop users
> suffering from bugs are just going to have to upgrade to a recent
> release where their issue is more likely to get addressed.
Agreed. I'll use the same algorithm for all the kernels then.
> I think that if this helps your ability to triage and categorize bugs,
> then you should do what you need to, as long as you keep producing the
> Recommended Bug List. In practice, your recommended bug list is about
> the only thing I (or any of the kernel team members) look at when
> deciding what to work on.
Yup, I'll definitely keep sending out the recommended bug list. Aside
from some extra bug mail you'll probably see, I'm hoping this won't
produce any major distractions or interruptions for you guys.
More information about the kernel-team