Re: deprecating more kernel versions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Mon, Feb 6, 2017 at 8:20 PM, Luca Coelho <luca@xxxxxxxxx> wrote:
> On Mon, 2017-02-06 at 23:45 +0100, Arend Van Spriel wrote:
> > On 6-2-2017 17:37, Johannes Berg wrote:
> > > What kernel versions do you still need?
> > >
> > > For example, 3.0 is getting really quite old, the oldest long-term
> > > stable is 3.2.x now.
> >
> > We currently backport internal tree and wireless-testing nightly to 3.10
> > and 3.11 kernels.
> I think capping at 3.10 is reasonable.  Internally, we have been
> supporting 3.8+, but we got permission to support only 3.12 and above.
> Last time we nuked support for older kernels [1], we were supporting
> only 15 kernel versions (3.0 through 3.14).  Now we are at 30 (3.0
> through 4.10 -- sort of).  If we make the cut at 3.10 we are at 20,
> which is still a lot more conservative than our last "nuke".
> [1]

Maybe this comes from ignorance or inexperience, but I'll throw out a
few questions/thoughts.

* Do we have a policy on how far back or when/how we deprecate versions?
* What is the implication of doing so?  For example, is it a "we don't
bother testing with versions less than 3.10"? or "it's going to stop
working for < 3.10?"
* Is a deprecation in this case a warning we're not going to be
supporting a version soon, or are we immediately dropping support?
* And finally the big one - what's the implication of _keeping_ a
particular older version alive.

I think an "official" position on the above would be appropriate and
perhaps we should decide something and publish that.  And then the
question won't come up anymore... we'll just deprecate at the correct

All that said, here's my issue - we still have customers doing
integrations with our radios, supported via backports, as far back as
2.6.33!  Yes, that's NEW integrations. Usually has to do with BSPs
that haven't been updated. Right now, to support that we're
maintaining two backport "releases" one based on the 3.13 kernel for
<3.0and one based on our 4.4.x kernel for the more modern ones (3.0+).

We can continue to do things like that, but I don't want to keep
adding and maintaining older forks.

But, that's _my_ problem, and it's a commercial problem, and doesn't
need to be the community's problem.

I would say that Luca's suggestion of 3.10 is perfectly reasonable.
However, wouldn't it make sense to always support back to the current
oldest LTS (3.2)? It seems odd that we'd cap higher than a valid LTS.

I'll throw out another thought: what would be the implications of
supporting all current non-eol LTS + all versions say the past 6 (pick
a number). So that'd be 3.2, 3.6, 3.10, 3.12, 3.16, 4.1, 4.4..4.10.
Does that reduce the work, or does going all the way back to 3.2, even
if we don't test and be sure say 3.3 works, still means we're doing
all those version from 3.2 on?

Just throwing out ideas for thought and discussion.

And, I'm fine with 3.10 being the oldest we support.

- Steve
To unsubscribe from this list: send the line "unsubscribe backports" in

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux