Kernel Bug Migration

[Tim Gardner]

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.

>> In all honesty, that class of bugs will never get any attention, so why not
>> just close them as "Won't fix" ?
> 
> At least for the 2.6.17, 2.6.20, and 2.6.22 bugs we are closing them as
> "Won't Fix" with a request to test the latest release.  We're then
> automatically opening and setting the linux task to Incomplete until
> they test and provide feedback.  So these should stay off your radar
> until they're actually tested and confirmed to exist against the latest
> release.
> 
> 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.

>> I'm much more interested in fixing the
>> current version issues because that is where my efforts have the most
>> bang for the buck. I'm far more likely to be able to find an upstream
>> patch for a _recent_ release of the kernel or driver, and its rare that
>> the kernel team has the time or hardware resources to develop a patch
>> from scratch (which is what we would have to do in most cases for older
>> releases). Its simply not cost effective to fix a bug on an older
>> release that affect a very few people when I can be working on one that
>> affects many more.
> 
> Agreed.  I know your guys' time is best spent focusing on the bugs which
> affect the current release.  However, I don't think that means we should
> just ignore legitimate kernel bugs reported against older kernel
> releases but may still exist in the current one.
> 
>> It appears to me that migrating these bugs to a common package will make
>> it more difficult for me to weed through the bug list in order to decide
>> what to work on.
> 
> Hopefully by setting the bugs to "Won't Fix" for the older kernels and
> "Incomplete" for the recent kernel, they should stay off your radar
> until they are confirmed to exist in the latest release.
> 
> Thoughts on this?
> 
> Thanks for the feedback already,
> Leann
> 

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.

rtg
-- 
Tim Gardner tim.gardner at ubuntu.com