Re: [Ksummit-discuss] [CORE TOPIC] stable issues

[Ben Hutchings <ben@decadent.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]

On Sun, 2014-05-04 at 19:19 +0800, Li Zefan wrote:
> I've been dealing with stable kernels. There are some issues that I noticed
> and may be worth discussing.
> 
> - Too many LTS kernels?

Or in another sense, maybe too few?  Less than 5 years' support is
hardly long-term, though I would not volunteer for backporting so far.

> 2.6.32  Willy Tarreau
> 3.2     Ben Huchings
> 3.4     Greg
> 3.10    Greg
> 3.12    Jiry Slaby
> 
> Too many or not? Is it good or bad? One of the problem is the maintenance
> burden. For example, DaveM has to prepare stable patches for 5 stable
> kernels: 3.2, 3.4, 3.10, 3.12 and 3.14.
> 
> - Equip Greg with a sub-maintainer?
> 
> I found 3.4.x lacked hundreds of fixes compared to 3.2.x. It's mainly
> because Ben has been manually backporting patches which don't apply
> cleanly, while Greg just doesn't have the time budget.
>
> Is it possible that we find a sub-maintainer to do this work?

This is being addressed by others.

[...]
> - Testing stable kernels
> 
> The testing of stable kernels when a new version is under review seems
> quite limited. We have Dave's Trinity and Fengguang's 0day, but they
> are run on mainline/for-next only. Would be useful to also have them
> run on stable kernels?

According to my notes from Fengguang's talk, his robot excludes any
branch with a very old commit.  If that meant checking *commit* date,
not author date, then stable branches would already get tested as soon
as they are pushed to git.kernel.org.  As that doesn't seem to be
happening, it seems like the test must be based on author date and
should be changed to commit date.  But also, we would need to commit
each rc patch series to a git branch.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
                                                           - Albert Einstein

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]