Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #52478 > unrolled thread

Kernel version for stretch

Back to article view | Back to linux.debian.kernel

Contents

  Kernel version for stretch Ben Hutchings <ben@decadent.org.uk> - 2016-01-27 19:30 +0100
    Re: Kernel version for stretch Moritz Mühlenhoff <jmm@inutil.org> - 2016-01-28 20:10 +0100
      Re: Kernel version for stretch Ben Hutchings <ben@decadent.org.uk> - 2016-01-28 21:20 +0100
        Re: Kernel version for stretch Moritz Mühlenhoff <jmm@inutil.org> - 2016-01-30 15:40 +0100
          Re: Kernel version for stretch Philipp Kern <pkern@debian.org> - 2016-02-07 02:00 +0100
      Re: Kernel version for stretch maximilian attems <maks@stro.at> - 2016-01-29 00:10 +0100
        Re: Kernel version for stretch Moritz Muehlenhoff <jmm@inutil.org> - 2016-01-30 15:40 +0100
          Re: Kernel version for stretch maximilian attems <maks@stro.at> - 2016-01-30 18:40 +0100
    Re: Kernel version for stretch Niels Thykier <niels@thykier.net> - 2016-02-02 08:50 +0100
      Re: Kernel version for stretch Cyril Brulebois <kibi@debian.org> - 2016-02-02 14:30 +0100
        Re: Kernel version for stretch Karsten Merker <merker@debian.org> - 2016-02-03 08:40 +0100
          Re: Kernel version for stretch Rick Thomas <rbthomas@pobox.com> - 2016-02-03 19:40 +0100
          Re: Kernel version for stretch Martin Michlmayr <tbm@cyrius.com> - 2016-02-04 04:40 +0100
      Re: Kernel version for stretch Karsten Merker <merker@debian.org> - 2016-02-03 08:30 +0100
      Re: Kernel version for stretch Ben Hutchings <ben@decadent.org.uk> - 2016-02-05 04:10 +0100
        Re: Kernel version for stretch Niels Thykier <niels@thykier.net> - 2016-02-05 19:50 +0100
          Re: Kernel version for stretch Ben Hutchings <ben@decadent.org.uk> - 2016-02-14 17:00 +0100
            Re: Kernel version for stretch Martin Michlmayr <tbm@cyrius.com> - 2016-02-14 21:50 +0100
              Re: Kernel version for stretch Ben Hutchings <ben@decadent.org.uk> - 2016-02-15 13:20 +0100
      Re: Kernel version for stretch Mehdi Dogguy <mehdi@dogguy.org> - 2016-02-15 09:50 +0100
    [Decision] Kernel version for stretch Niels Thykier <niels@thykier.net> - 2016-02-24 22:50 +0100
      Re: [Decision] Kernel version for stretch Ben Hutchings <ben@decadent.org.uk> - 2016-03-02 12:30 +0100

Page 1 of 2  [1] 2  Next page →

#52478 — Kernel version for stretch

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [next] | [standalone]

#52492

Ben Hutchings <ben@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

[toc] | [prev] | [next] | [standalone]

#52493

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2016-01-28 at 20:01 +0100, Moritz Mühlenhoff wrote:
> Ben Hutchings <ben@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.

[toc] | [prev] | [next] | [standalone]

#52507

On Thu, Jan 28, 2016 at 08:15:30PM +0000, Ben Hutchings wrote:
> On Thu, 2016-01-28 at 20:01 +0100, Moritz Mühlenhoff wrote:
> > Ben Hutchings <ben@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

[toc] | [prev] | [next] | [standalone]

#52602

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&do=get&target=Ubuntu+Kernel+Release+Schedule.png

[toc] | [prev] | [next] | [standalone]

#52494

On Thu, Jan 28, 2016 at 08:01:13PM +0100, Moritz Mühlenhoff wrote:
> Ben Hutchings <ben@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

[toc] | [prev] | [next] | [standalone]

#52506

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 <ben@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

[toc] | [prev] | [next] | [standalone]

#52511

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.

[toc] | [prev] | [next] | [standalone]

#52544

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#52547

[Multipart message — attachments visible in raw view] — view raw

Hi,

(Thanks for the prod.)

Niels Thykier <niels@thykier.net> (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.

[toc] | [prev] | [next] | [standalone]

#52555

On Tue, Feb 02, 2016 at 02:23:06PM +0100, Cyril Brulebois wrote:
> Niels Thykier <niels@thykier.net> (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
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[toc] | [prev] | [next] | [standalone]

#52567

On Feb 2, 2016, at 11:28 PM, Karsten Merker <merker@debian.org> wrote:

> On Tue, Feb 02, 2016 at 02:23:06PM +0100, Cyril Brulebois wrote:
>> Niels Thykier <niels@thykier.net> (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

[toc] | [prev] | [next] | [standalone]

#52572

* Karsten Merker <merker@debian.org> [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/

[toc] | [prev] | [next] | [standalone]

#52554

On Tue, Feb 02, 2016 at 07:34:15AM +0000, Niels Thykier wrote:

> Pulling in d-i on this, since they might be affected by this.
[...]
> > 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.
[...]
> @Kernel+d-i - What is your take on the following:
[...]
>  * If we were to stick with 4.4, what we will be missing out on?

>From the ARM architecture viewpoint I would very much like to see
a stretch release with kernel 4.10 instead of kernel 4.4.  In
particular regarding arm64 there is currently a lot of work done
to add proper mainline support for affordable hardware (Pine64,
Olimex A64-Olinuxino, boards from the 96boards initiative) that
we would miss if we release with kernel 4.4.

On armhf we would also miss quite a bit of important hardware
support improvements if we release with kernel 4.4 (in particular
KMS display driver and audio support for a large number of armhf
boards that we support only headless in jessie; patches are
currently in the review phase and will hopefully go into kernel
4.6/4.7).

Another issue with kernel 4.4 is that at the release time of
stretch a large part of the long-term support period for 4.4 will
already be over, so the maintainance effort for the Debian kernel
maintainers will be higher than with kernel 4.10.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[toc] | [prev] | [next] | [standalone]

#52579

[Multipart message — attachments visible in raw view] — view raw

On Tue, 2016-02-02 at 07:34 +0000, 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.1
0
>    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

[toc] | [prev] | [next] | [standalone]

#52591

[Multipart message — attachments visible in raw view] — view raw

Ben Hutchings:
> On Tue, 2016-02-02 at 07:34 +0000, 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

[toc] | [prev] | [next] | [standalone]

#52842

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2016-02-05 at 18:48 +0000, Niels Thykier wrote:
> Ben Hutchings:
> > On Tue, 2016-02-02 at 07:34 +0000, 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.

[toc] | [prev] | [next] | [standalone]

#52846

* Ben Hutchings <ben@decadent.org.uk> [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/

[toc] | [prev] | [next] | [standalone]

#52848

[Multipart message — attachments visible in raw view] — view raw

On Sun, 2016-02-14 at 15:48 -0500, Martin Michlmayr wrote:
> * Ben Hutchings <ben@decadent.org.uk> [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

[toc] | [prev] | [next] | [standalone]

#52847

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web