Re: [Decision] Kernel version for stretch

[Ben Hutchings]

I read this last week just before slipping into a fever in which I had
recurring dreams about the relations of unnameable abstract entities
that seemed later to correspond to software components.

On recovering from the flu, I was pleased to find that I hadn't
imagined that Niels Thykier wrote:
> Hi,
> 
> On the Release Team's IRC meeting today we concluded the following[1]:
> 
>  * We expect to release Stretch with the LTS release based on Linux 4.10
>  * We intend to delay the freeze (all milestone dates) by 2 months to
>    accommodate the above.
>    - Note that the expected release date of Linux 4.10 will then fall
>  between the "new" freeze and the "deep" freeze.

Thank you very much for accommodating this request!

>  * The linux 4.10 release will be entitled to a freeze exception if it
>    misses "deep freeze" by 5th of Feb.
>    - This exception only applies to linux.
>  * We would like to encourage the Linux kernel maintainers to upload
>    release candidates of Linux 4.10 in sid.
>    - The sooner we can spot regressions/problems in reverse
>  dependencies, the better.

Given the recent changes in linux packaging made to support easy
derivation of source packages such as linux-grsec, it should be easy to
upload a temporary linux-4.10 source package in parallel with linux.

This would allow rollback from 4.10 to 4.9 simply by changing which
version the linux-latest package refers to - no fake version or epoch
would be needed to make the 4.9 packages look newer.

> This decision is based on assumptions about the current release schedule
> of the Linux kernel.  Should the expected release date for the LTS
> change considerably, we may have to revise the decision.
[...]

And of course I'll let you know if the kernel release cycle deviates
significantly from expected.

Ben.

-- 
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.

signature.asc
Description: This is a digitally signed message part

[Decision] Kernel version for stretch

[Niels Thykier]

Hi,

On the Release Team's IRC meeting today we concluded the following[1]:

 * We expect to release Stretch with the LTS release based on Linux 4.10
 * We intend to delay the freeze (all milestone dates) by 2 months to
   accommodate the above.
   - Note that the expected release date of Linux 4.10 will then fall
 between the "new" freeze and the "deep" freeze.
 * The linux 4.10 release will be entitled to a freeze exception if it
   misses "deep freeze" by 5th of Feb.
   - This exception only applies to linux.
 * We would like to encourage the Linux kernel maintainers to upload
   release candidates of Linux 4.10 in sid.
   - The sooner we can spot regressions/problems in reverse
 dependencies, the better.

This decision is based on assumptions about the current release schedule
of the Linux kernel.  Should the expected release date for the LTS
change considerably, we may have to revise the decision.

This mail is intended as a heads up to the parties involved (and not as
a replacement of the official announcement).  We will include it in our
upcoming "bits from the release team", which is due soon.

Thanks,
~Niels

[1]
http://meetbot.debian.net/debian-release/2016/debian-release.2016-02-24-18.59.html





signature.asc
Description: OpenPGP digital signature

Re: Kernel version for stretch

[Ben Hutchings]

On Sun, 2016-02-14 at 15:48 -0500, Martin Michlmayr wrote:
> * Ben Hutchings  [2016-02-14 15:58]:
> > >  * If we stick with 4.4, the Debian Linux maintainers receives
> > >    practically no advantage from Greg's LTS effort.
> > 
> > No, we would benefit from that but this is very early to freeze the
> > kernel and we would need to do a lot of work on backporting hardware
> > support.
> 
> Based on my gut feeling, backporting stuff into 4.4 would be more work
> than doing a long-term stable release based on 4.9.  Based on your
> experience, do you think that's accurate, Ben?

I think they're around the same amount of effort.

> (I think it would be different if we were to use 4.4 when 4.5 was the
> current kernel, but 4.4 to 4.10 is going to be a huge delta.)
> 
> So imho we should get 4.9 into unstable, agree at some point on 4.9 vs
> 4.10 and if we agree on 4.10 then get 4.10-rc releases into unstable,
> and ask people to test daily d-i images based on that.

Yes, that's a good way to reduce the risk of a late switch.

> (Of course I should mention that I'm not part of the kernel team.  But
> speaking as an ARM porter, I think going with 4.4 would be a disaster.
> We're going to see a lot of changes this year, especially on ARM64.)

I know.

> Another option would be to go with 4.4 and make it easy for d-i to
> support kernels from backports (something we should do anyway).  But I
> think releasing with a 1.5 year old kernel is just going to add to the
> "Debian is out of date" view.

There's that too.

Ben.

-- 
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg

signature.asc
Description: This is a digitally signed message part

Re: Kernel version for stretch

[Mehdi Dogguy]

Hi,

On 2016-02-02 08:34, Niels Thykier wrote:
Based on the current 9 week upstream release cycle, the longterm 
branch
for 2017 will presumably be based on Linux 4.10, released at the end 
of

week 3 (22nd January 2017).  That's well after the planned stretch
freeze date so I don't see how it can be included.



Indeed that is a bit unfortunate.  With the freeze date already
announced, I am very hesitant to move it.



I wouldn't consider it a fail if we decided to shift the freeze date by
two months [1], especially if this move helps project members to 
integrate
better supported versions for their packages. Eventually, it would help 
us

to have a better quality release and enhance its supportability over the
years.

Having that said, it would be nice to hear from Ben if it would be 
doable

to go with 4.9 or with a 4.10rc for some time.

[1] only a few persons seem to have noted those dates anyway (imho).

--
Mehdi

Re: Kernel version for stretch

[Martin Michlmayr]

* Ben Hutchings  [2016-02-14 15:58]:
> >  * If we stick with 4.4, the Debian Linux maintainers receives
> >    practically no advantage from Greg's LTS effort.
> 
> No, we would benefit from that but this is very early to freeze the
> kernel and we would need to do a lot of work on backporting hardware
> support.

Based on my gut feeling, backporting stuff into 4.4 would be more work
than doing a long-term stable release based on 4.9.  Based on your
experience, do you think that's accurate, Ben?

(I think it would be different if we were to use 4.4 when 4.5 was the
current kernel, but 4.4 to 4.10 is going to be a huge delta.)

So imho we should get 4.9 into unstable, agree at some point on 4.9 vs
4.10 and if we agree on 4.10 then get 4.10-rc releases into unstable,
and ask people to test daily d-i images based on that.

(Of course I should mention that I'm not part of the kernel team.  But
speaking as an ARM porter, I think going with 4.4 would be a disaster.
We're going to see a lot of changes this year, especially on ARM64.)

Another option would be to go with 4.4 and make it easy for d-i to
support kernels from backports (something we should do anyway).  But I
think releasing with a 1.5 year old kernel is just going to add to the
"Debian is out of date" view.

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: Kernel version for stretch

[Ben Hutchings]

On Fri, 2016-02-05 at 18:48 +, Niels Thykier wrote:
> Ben Hutchings:
> > On Tue, 2016-02-02 at 07:34 +, Niels Thykier wrote:
[...]
> > I thought that 10 week cycles were rare, but I checked this and now I'm
> > much less confident.  Rounding to the nearest week, the distribution of
> > release cycle lengths from 3.2 to 4.4 inclusive, is:
> > 
> >  8 weeks: *   ( 1)
> >  9 weeks: **  (10)
> > 10 weeks: **  (10)
> > 11 weeks: **  ( 2)
> > 
> > (I chose this range to exclude the 3.1 release delayed by the
> > kernel.org compromise.)
> > 
> > So it seems quite possible that 4.10 could be released later in January
> > or in February.
> > 
> > [...]
> 
> Ok, so a reasonable guess would be actually be 10 weeks, which puts us
> at the 29th of January?  An upstream stable update would come 3-4 weeks
> later.

The earlier cycles might also be 10 weeks, which adds more uncertainty.

[...]
> > >    - How long does Greg's LTS last?  We would spend at least a year of
> > >  it before January 22nd 2017.
> > 
> > About 15 months.
> >
> > [...]
> 
> So Greg's LTS will almost be over by the time 4.10 is released? Seems
> like we are not getting a lot from sticking with 4.4 then?

Sorry, either I mixed up maintainers there or I meant to say that we
would have 15 months *after* January 2017.  Greg typically maintains a
'longterm' branch for about 27 months:

2.6.32: 2009-12 .. 2012-03 (then transferred to Willy Tarreau)
3.0:2011-07 .. 2013-10
3.4:2012-05 .. 2014-08 (then transferred to Zefan Li)

So we can expect:

4.4:    2016-01 .. 2018-04

> From what I can gather so far:
> 
>  * We are looking at moving the freeze at least 2 months if we want
>    Linux 4.10.
>    - At +2 months, Linux 4.10 would be just before the "deep freeze"
>  (Assuming a 10 week release cycle for Linux).
> 
>  * If we stick with 4.4, the Debian Linux maintainers receives
>    practically no advantage from Greg's LTS effort.

No, we would benefit from that but this is very early to freeze the
kernel and we would need to do a lot of work on backporting hardware
support.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.

signature.asc
Description: This is a digitally signed message part

Re: Kernel version for stretch

[Philipp Kern]

On Sat, Jan 30, 2016 at 03:34:16PM +0100, Moritz Mühlenhoff wrote:
> I would need to confirm that, but AFAICS the non-LTS kernels after 3.11 are
> all maintained for two years (since they are now made available at "hardware
> enablement kernels" for the Ubuntu LTS releases.

Non-LTS kernels can be quite short. [1] visualizes that. For instance
once the new LTS and the HWE got backported to the old LTS, all
intermediate ones (except base + new LTS) are dropped pretty much
instantly. You are also expected to migrate HWEs in the meantime
when new ones are made available.

Kind regards
Philipp Kern

[1] 
https://wiki.ubuntu.com/Kernel/Support?action=AttachFile=get=Ubuntu+Kernel+Release+Schedule.png

Re: Kernel version for stretch

[Niels Thykier]

Ben Hutchings:
> On Tue, 2016-02-02 at 07:34 +, Niels Thykier wrote:
> [...]
>>
>> Would you prefer that we moved future freezes (i.e. Buster and later),
>> so we could always rely on Greg's branch?
> 
> Yes, I would.
> 

Ok, we will take it into consideration for the planning of the next freeze.

> [...]
>>- How certain are we on the 22nd being the actual release date?
> 
> I thought that 10 week cycles were rare, but I checked this and now I'm
> much less confident.  Rounding to the nearest week, the distribution of
> release cycle lengths from 3.2 to 4.4 inclusive, is:
> 
>  8 weeks: *   ( 1)
>  9 weeks: **  (10)
> 10 weeks: **  (10)
> 11 weeks: **  ( 2)
> 
> (I chose this range to exclude the 3.1 release delayed by the
> kernel.org compromise.)
> 
> So it seems quite possible that 4.10 could be released later in January
> or in February.
> 
> [...]

Ok, so a reasonable guess would be actually be 10 weeks, which puts us
at the 29th of January?  An upstream stable update would come 3-4 weeks
later.

>>  * How difficult/disruptive do you expect the migration to linux 4.10
>>will be?
>>- Is this something we can reasonably do within a month?  2 months?
> 
> Migration from what, 4.9?
> 

Yes - on the assumption that we are going to use 4.10, I presume it
would be easiest to upgrade from 4.9 rather than 4.4 (admittedly, I am
ignoring roll-backs for a moment).

>> [...]
> 
>>- How long does Greg's LTS last?  We would spend at least a year of
>>  it before January 22nd 2017.
> 
> About 15 months.
> 
> [...]

So Greg's LTS will almost be over by the time 4.10 is released? Seems
like we are not getting a lot from sticking with 4.4 then?



From what I can gather so far:

 * We are looking at moving the freeze at least 2 months if we want
   Linux 4.10.
   - At +2 months, Linux 4.10 would be just before the "deep freeze"
 (Assuming a 10 week release cycle for Linux).

 * If we stick with 4.4, the Debian Linux maintainers receives
   practically no advantage from Greg's LTS effort.


Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: Kernel version for stretch

[Ben Hutchings]

On Tue, 2016-02-02 at 07:34 +, Niels Thykier wrote:
[...]
> > Greg's new policy is to pick the first Linus release in each year for
> > longterm maintenance.  The longterm branch for 2016 is based on Linux
> > 4.4, released at the end of week 1 (10th January).  By the time stretch
> > is released, 4.4 will be quite old (the same problem squeeze and wheezy
> > had, requiring many driver backports).
> > 
> 
> Would you prefer that we moved future freezes (i.e. Buster and later),
> so we could always rely on Greg's branch?

Yes, I would.

> Not knowing Linux's LTS planning:
> 
>  * Does Greg do an LTS *every* year? OR,

He has done so every year since 2008, except for 2010.

Following discussion at last year's kernel summit, he agreed to start
an LTS branch from the first release of each year, which should be
within the first 9 weeks of the year.

[...]
> @Kernel+d-i - What is your take on the following:
> 
>  * How long will it take to have the new release ready?
>    - That is, the latency between the 22nd and us having it in unstable.

Usually we would upload a new upstream release to experimental and wait
for at least the first stable update before uploading to unstable.
That means a delay of about 3 weeks.  But we could decide to take the
risk of uploading early to unstable, even starting with release
candidates to flush out bugs that will affect Debian users.

>    - How certain are we on the 22nd being the actual release date?

I thought that 10 week cycles were rare, but I checked this and now I'm
much less confident.  Rounding to the nearest week, the distribution of
release cycle lengths from 3.2 to 4.4 inclusive, is:

 8 weeks: *           ( 1)
 9 weeks: **  (10)
10 weeks: **  (10)
11 weeks: **          ( 2)

(I chose this range to exclude the 3.1 release delayed by the
kernel.org compromise.)

So it seems quite possible that 4.10 could be released later in January
or in February.

[...]
>  * How difficult/disruptive do you expect the migration to linux 4.10
>    will be?
>    - Is this something we can reasonably do within a month?  2 months?

Migration from what, 4.9?

>    - Can we plan ahead to reduce the time / issues?  Maybe use
>  linux pre-releases?

Yes, that's an option.  Thanks to early integration testing (linux-
next), Linux release candidates are less of a risk than they used to
be.

>    - If we start this, is it in anyway reasonable to do a roll-back
>  within 2-3 weeks?  (I am guessing "no", but I figured I'd ask.)

I think it would be doable, but it would probably require the earlier
kernel version to be re-uploaded as a new source package to satisfy
dak.

>  * If we were to stick with 4.4, what we will be missing out on?
>    - Are there any planned/known "must haves"?

Primarily hardware support - we would likely need to backport support
for newer GPUs, Ethernet, wifi and SCSI controllers in PCs and for new
ARM-based SoCs and platforms.

>    - How long does Greg's LTS last?  We would spend at least a year of
>  it before January 22nd 2017.

About 15 months.

> > (By the way, I haven't seen the stretch freeze dates announced
> > anywhere; I only found them on a wiki page.  A new "Bits from the
> > release team" seems to be overdue.)
> > 
> > Ben.
> > 
> 
> A bits is indeed overdue.  The announcement happened in the Release Team
> talk at DebConf15.

Thanks.  I knew I had seen dates somewhere, and that must have been
where I saw them.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein

signature.asc
Description: This is a digitally signed message part

Re: Kernel version for stretch

[Martin Michlmayr]

* Karsten Merker  [2016-02-03 08:28]:
> > Having people around to test d-i daily builds until the kernel reaches 
> > testing
> > would be nice, so that we don't wait until the d-i upload (and maybe d-i 
> > image
> > builds) using testing's kernel to get some feedback.
> 
> I can offer to do that for a number of armhf platforms.

Same here for armel, armhf and arm64.

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: Kernel version for stretch

[Rick Thomas]

On Feb 2, 2016, at 11:28 PM, Karsten Merker  wrote:

> On Tue, Feb 02, 2016 at 02:23:06PM +0100, Cyril Brulebois wrote:
>> Niels Thykier  (2016-02-02):
>>> @Kernel+d-i - What is your take on the following:
>>> 
>>> * How long will it take to have the new release ready?
>>>   - That is, the latency between the 22nd and us having it in unstable.
>>>   - How certain are we on the 22nd being the actual release date?
>>>   - [d-i]: How long will it take to have a d-i using the new linux
>>> ready?
>> 
>> Once the new ABI reaches unstable, d-i can be patched to use it instead of 
>> the
>> old one. That's a one-liner patch. In case udebs are modified we might need 
>> to
>> also update a few lists accordingly, but as usual that can be done 
>> proactively
>> if the kernel team tells us that this or that udeb is getting dropped or 
>> added.
>> 
>> Having people around to test d-i daily builds until the kernel reaches 
>> testing
>> would be nice, so that we don't wait until the d-i upload (and maybe d-i 
>> image
>> builds) using testing's kernel to get some feedback.
> 
> I can offer to do that for a number of armhf platforms.
> 
> Regards,
> Karsten

And I can offer to do that for old Macintosh PowerPC (G4, G5) and armel 
(SheevaPlug, OpenRD) hardware.

Enjoy!
Rick

Re: Kernel version for stretch

[Cyril Brulebois]

Hi,

(Thanks for the prod.)

Niels Thykier  (2016-02-02):
> @Kernel+d-i - What is your take on the following:
> 
>  * How long will it take to have the new release ready?
>- That is, the latency between the 22nd and us having it in unstable.
>- How certain are we on the 22nd being the actual release date?
>- [d-i]: How long will it take to have a d-i using the new linux
>  ready?

Once the new ABI reaches unstable, d-i can be patched to use it instead of the
old one. That's a one-liner patch. In case udebs are modified we might need to
also update a few lists accordingly, but as usual that can be done proactively
if the kernel team tells us that this or that udeb is getting dropped or added.

Having people around to test d-i daily builds until the kernel reaches testing
would be nice, so that we don't wait until the d-i upload (and maybe d-i image
builds) using testing's kernel to get some feedback.


Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Kernel version for stretch

[Niels Thykier]

Hi Ben,

Pulling in d-i on this, since they might be affected by this.  If you
know of a maintainer that would be similarly affected, let me know, so
we can ask them as well.

Ben Hutchings:
> [...]
> 
> For stretch, I would very much like to choose a kernel version for
> stretch that gets longterm maintenance by Greg Kroah-Hartman.  That
> lasts 2 years from release, after which someone else (maybe me) can
> take over.  I do not want to maintain 3 kernel longterm branches at a
> time, and there is consensus among the stable maintainers that it is
> undesirable to have more than one longterm branch started per year.
> 

Noted.

> Greg's new policy is to pick the first Linus release in each year for
> longterm maintenance.  The longterm branch for 2016 is based on Linux
> 4.4, released at the end of week 1 (10th January).  By the time stretch
> is released, 4.4 will be quite old (the same problem squeeze and wheezy
> had, requiring many driver backports).
> 

Would you prefer that we moved future freezes (i.e. Buster and later),
so we could always rely on Greg's branch?  Not knowing Linux's LTS planning:

 * Does Greg do an LTS *every* year? OR,
 * is "each year for longterm maintenance" like Ubuntu's were they have
   years without LTS?

> Based on the current 9 week upstream release cycle, the longterm branch
> for 2017 will presumably be based on Linux 4.10, released at the end of
> week 3 (22nd January 2017).  That's well after the planned stretch
> freeze date so I don't see how it can be included.
> 

Indeed that is a bit unfortunate.  With the freeze date already
announced, I am very hesitant to move it.

> Can you suggest any way to resolve this?
> 

@Kernel+d-i - What is your take on the following:

 * How long will it take to have the new release ready?
   - That is, the latency between the 22nd and us having it in unstable.
   - How certain are we on the 22nd being the actual release date?
   - [d-i]: How long will it take to have a d-i using the new linux
 ready?

 * How difficult/disruptive do you expect the migration to linux 4.10
   will be?
   - Is this something we can reasonably do within a month?  2 months?
   - Can we plan ahead to reduce the time / issues?  Maybe use
 linux pre-releases?
   - If we start this, is it in anyway reasonable to do a roll-back
 within 2-3 weeks?  (I am guessing "no", but I figured I'd ask.)

 * If we were to stick with 4.4, what we will be missing out on?
   - Are there any planned/known "must haves"?
   - How long does Greg's LTS last?  We would spend at least a year of
 it before January 22nd 2017.


> (By the way, I haven't seen the stretch freeze dates announced
> anywhere; I only found them on a wiki page.  A new "Bits from the
> release team" seems to be overdue.)
> 
> Ben.
> 

A bits is indeed overdue.  The announcement happened in the Release Team
talk at DebConf15.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: Kernel version for stretch

[maximilian attems]

On Sat, Jan 30, 2016 at 03:30:37PM +0100, Moritz Muehlenhoff wrote:
> On Thu, Jan 28, 2016 at 11:42:13PM +0100, maximilian attems wrote:
> > 
> > Well, those efforts have not a good track record, afais Ben is maintaining
> > their lts Linus.
> 
> I don't really understand the second half of your sentence,

one funny typo, here s/Linus/Linux/.

> but they certainly
> have a good track record: After all Jessie is based on their ckt 3.16 series
> and their 3.19 kernel is also working very well (we're using it at work 
> on top of jessie since 3.16 has some mm problems under high load). I've been 
> forwarding patches for merging to Luis and Kamal for quite a while now and 
> they've always been really responsive and helpful.

It is not an upstream sanctioned stable release and Jessie ended up squeezed.

Re: Kernel version for stretch

[Moritz Muehlenhoff]

On Thu, Jan 28, 2016 at 11:42:13PM +0100, maximilian attems wrote:
> On Thu, Jan 28, 2016 at 08:01:13PM +0100, Moritz Mühlenhoff wrote:
> > Ben Hutchings <b...@decadent.org.uk> wrote:
> > > For stretch, I would very much like to choose a kernel version for
> > > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > > lasts 2 years from release, after which someone else (maybe me) can
> > > take over.
> > 
> > Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> > for Ubuntu-non-LTS releases for two years.
> > 
> 
> Well, those efforts have not a good track record, afais Ben is maintaining
> their lts Linus.

I don't really understand the second half of your sentence, but they certainly
have a good track record: After all Jessie is based on their ckt 3.16 series
and their 3.19 kernel is also working very well (we're using it at work 
on top of jessie since 3.16 has some mm problems under high load). I've been 
forwarding patches for merging to Luis and Kamal for quite a while now and 
they've always been really responsive and helpful.

Cheers,
Moritz

Re: Kernel version for stretch

[Moritz Mühlenhoff]

On Thu, Jan 28, 2016 at 08:15:30PM +, Ben Hutchings wrote:
> On Thu, 2016-01-28 at 20:01 +0100, Moritz Mühlenhoff wrote:
> > Ben Hutchings <b...@decadent.org.uk> wrote:
> > > For stretch, I would very much like to choose a kernel version for
> > > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > > lasts 2 years from release, after which someone else (maybe me) can
> > > take over.
> > 
> > Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> > for Ubuntu-non-LTS releases for two years.
> 
> Not in general; it can be as little as 12 months (e.g. 3.11-ckt).

I would need to confirm that, but AFAICS the non-LTS kernels after 3.11 are
all maintained for two years (since they are now made available at "hardware
enablement kernels" for the Ubuntu LTS releases.

> > We could base the stretch kernel on the underlying ckt kernel
> > series used for Ubuntu 16.04 or 16.10?
> 
> Given the politics involved, I would rather not do that twice in a row.

Ok.

Cheers,
Moritz

Re: Kernel version for stretch

[Moritz Mühlenhoff]

Ben Hutchings <b...@decadent.org.uk> wrote:
> For stretch, I would very much like to choose a kernel version for
> stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> lasts 2 years from release, after which someone else (maybe me) can
> take over.

Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
for Ubuntu-non-LTS releases for two years.

We could base the stretch kernel on the underlying ckt kernel
series used for Ubuntu 16.04 or 16.10?

Cheers,
Moritz

Re: Kernel version for stretch

[Ben Hutchings]

On Thu, 2016-01-28 at 20:01 +0100, Moritz Mühlenhoff wrote:
> Ben Hutchings <b...@decadent.org.uk> wrote:
> > For stretch, I would very much like to choose a kernel version for
> > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > lasts 2 years from release, after which someone else (maybe me) can
> > take over.
> 
> Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> for Ubuntu-non-LTS releases for two years.

Not in general; it can be as little as 12 months (e.g. 3.11-ckt).

> We could base the stretch kernel on the underlying ckt kernel
> series used for Ubuntu 16.04 or 16.10?

Given the politics involved, I would rather not do that twice in a row.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


signature.asc
Description: This is a digitally signed message part

Re: Kernel version for stretch

[maximilian attems]

On Thu, Jan 28, 2016 at 08:01:13PM +0100, Moritz Mühlenhoff wrote:
> Ben Hutchings <b...@decadent.org.uk> wrote:
> > For stretch, I would very much like to choose a kernel version for
> > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > lasts 2 years from release, after which someone else (maybe me) can
> > take over.
> 
> Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> for Ubuntu-non-LTS releases for two years.
> 

Well, those efforts have not a good track record, afais Ben is maintaining
their lts Linus.

-- 
maks

Kernel version for stretch

[Ben Hutchings]

I'm currently maintaining the Linux 3.2 longterm branch and will do so
until May 2018 (end of wheezy LTS).  I will also be taking over
maintenance of the 3.16 longterm branch soon, and assuming there is a
jessie LTS I will do so until April 2020.

For stretch, I would very much like to choose a kernel version for
stretch that gets longterm maintenance by Greg Kroah-Hartman.  That
lasts 2 years from release, after which someone else (maybe me) can
take over.  I do not want to maintain 3 kernel longterm branches at a
time, and there is consensus among the stable maintainers that it is
undesirable to have more than one longterm branch started per year.

Greg's new policy is to pick the first Linus release in each year for
longterm maintenance.  The longterm branch for 2016 is based on Linux
4.4, released at the end of week 1 (10th January).  By the time stretch
is released, 4.4 will be quite old (the same problem squeeze and wheezy
had, requiring many driver backports).

Based on the current 9 week upstream release cycle, the longterm branch
for 2017 will presumably be based on Linux 4.10, released at the end of
week 3 (22nd January 2017).  That's well after the planned stretch
freeze date so I don't see how it can be included.

Can you suggest any way to resolve this?

(By the way, I haven't seen the stretch freeze dates announced
anywhere; I only found them on a wiki page.  A new "Bits from the
release team" seems to be overdue.)

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.


signature.asc
Description: This is a digitally signed message part