Kernel Bug Migration

Tim Gardner tim.gardner at canonical.com
Tue Jun 10 09:20:02 UTC 2008


Leann Ogasawara wrote:
> Hi Guys,
> 
> As most of you know, beginning with the Hardy release cycle the Ubuntu
> kernel source package naming convention changed from linux-source-2.6.xx
> to just linux.  I think it is important that as we move forward we be
> sure to migrate any bugs open against older kernels to the most recent
> kernel.  Otherwise, I fear bugs may stagnate and go unaddressed.  There
> is a significant amount of bugs open against older Ubuntu kernels.
> Manually processing all these bugs by hand would be inefficient.  I'd
> like to propose automating the process of moving some of these bugs
> forward.  I've documented the process, criteria, and stock replies I'd
> like to use at the following wiki:
> 
> https://wiki.ubuntu.com/QATeam/KernelBugMigration
> 
> I'll inline portions of the wiki below.
> 
> Criteria:
>      1. Bug is not undergoing the SRU process (ubuntu-sru is not a
>         subscriber and the bug is not specifically targeted to a
>         release) 
>      2. Bug is not a security bug (security_related is true) 
>      3. Bug has less than or equal to (<=) 10 subscribers 
>      4. Bug must be against a linux-source-2.6.xx package and have a
>         Status of either New, Incomplete, Confirmed, or Triaged 
>      5. Bug must only be tasked to a single linux-source-2.6.xx package
>         (ie bugs against multiple kernel releases will not be handled in
>         this first pass) 
>      6. Bug does not already have a "linux" task (just reiterating
>         above) 
>      7. Bug is not a High or Critical bug - we should look at the High
>         and Critical bugs manually 
>      8. Bug is not In Progress or Fix Committed - these should be looked
>         at manually too as they may really be fixed
> 
> Process:
>      1. Launchpad janitor will automatically post a stock reply (see
>         wiki) depending on which kernel is being processed 
>      2. linux-source-2.6.15 bugs will be renamed to the new "linux"
>         kernel package. Also, tag these 'linux-source-2.6.15' to
>         maintain package history 
>      3. linux-source-2.6.17 bugs will be closed as Won't Fix as the 18
>         month support period has ended. The new "linux" task will be
>         added but marked as Incomplete. See stock reply for more info.
>         Also, tag these 'linux-source-2.6.17' to easily list which bugs
>         were migrated and isolate possible candidates to close if we've
>         received no response for testing with the latest release. 
>      4. linux-source-2.6.20 and linux-source-2.6.22 bugs will be marked
>         as Won't Fix. The new "linux" task will be added but marked as
>         Incomplete. See stock reply for more info. Also, tag these
>         'linux-source-2.6.20' or 'linux-source-2.6.22' to easily list
>         which bugs were migrated and isolate possible candidates to
>         close if we've received no response for testing with the latest
>         release. 
> 
> I'd appreciate any feedback you guys may have.  Ideally I'd like to
> start moving forward with this beginning in July.
> 
> Thanks,
> Leann
> 
> 

If I understand your algorithm correctly, you plan to migrate unpopular,
little noticed bugs from older releases. I'm wondering, why bother? In
all honesty, that class of bugs will never get any attention, so why not
just close them as "Won't fix" ? 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.

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.

rtg

-- 
Tim Gardner tim.gardner at ubuntu.com




More information about the kernel-team mailing list