deprecating more kernel versions

deprecating more kernel versions

[Johannes Berg]

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.

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

Re: deprecating more kernel versions

[Arend Van Spriel]

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.

Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: deprecating more kernel versions

[Luca Coelho]

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] https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/commit/?id=be4a0f9ad7e17670d7a30c9e94d5dd918425f90a

--
Cheers,
Luca.
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: deprecating more kernel versions

[Steve deRosier]

On Mon, Feb 6, 2017 at 8:20 PM, Luca Coelho <luca@coelho.fi> 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] https://git.kernel.org/cgit/linux/kernel/git/backports/backports.git/commit/?id=be4a0f9ad7e17670d7a30c9e94d5dd918425f90a
>


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
time.

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

Re: deprecating more kernel versions

[Johannes Berg]

> 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?

Not really.

> * 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?"

In practice, it's going to be both, since it's not working for < 3.10
today :)

> * Is a deprecation in this case a warning we're not going to be
> supporting a version soon, or are we immediately dropping support?

If we make a decision now we should drop it immediately, since
otherwise we still have to bring it up again first.

* And finally the big one - what's the implication of _keeping_ a
> particular older version alive.

It's just a bunch more work to backport more APIs that old kernels
didn't have.

> 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
> time.
> 
> 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+).

You can still add support for certain versions, even 2.6.33 if you
wish, I think. I have no problem for this to exist in the upstream
backport as well, but I don't want to be maintaining it myself.

Now, that said, 2.6.33 probably has some "special" challenges since
there was a lot of networking API changed somewhere around then, but
it's probably not impossible to do.

> 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?

It doesn't really make a significant difference, I think. Supporting
3.2 usually means supporting 3.3 as well, and then we might as well
compile-test 3.3 to make sure we didn't put an ifdef on 3.2 when it
should've been on 3.3.

For now I'm going to try to keep down to 3.0 and see what happens - I
haven't found any massive problem with that yet.

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