Re: Linux stable: 4.19 vs 4.14

From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Avinash Patil <avinashapatil@gmail.com>
Cc: kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: Linux stable: 4.19 vs 4.14
Date: Sat, 02 Nov 2019 13:54:17 -0400	[thread overview]
Message-ID: <17709.1572717257@turing-police> (raw)
In-Reply-To: <CAJwzM1=55GiNcgx6ZJk2op=UCZM3NKTQMnXGe2kXGbqnOQcksQ@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1836 bytes --]

On Fri, 01 Nov 2019 14:24:26 -0700, Avinash Patil said:
> Hi Greg,

I'm not Greg, but... :)

> I am curious as to why Linux4.19 which was released later has earlier
> EOL than 4.14?

Not all stable releases are kept going for the same amount of time.  Most go
EOL as soon as a few newer releases have come out, while every 5th one or so is
kept going for longer.

> If we have to choose one version over another for BSP, which one is preferred?

If you're planning to dump unsupported crap on customers, it doesn't matter.
Let's face it - if you're not going to provide updates, when a stable stream
EOLs doesn't matter if you ship 4.19.81 or 4.14.151, because your customers
aren't ever going to get 4.19.104 or 4.14.183.

But you probably want to base the BSP on 4.19 so that your customers get the benefit
of all the stuff that got fixed between 4.14 and 4.19.  Remember that only a *very* small
fraction of fixes - those that qualify under Documentation/process/stable-kernel-rules.rst
get included in the stable tree.

And of course, unless you have no intention of building similar boards in the future,
it's a good idea to upstream any custom drivers.  That way, when your follow-on
BSP gets based to the 5.11 kernel, your drivers are already in-tree, and even more
importantly, already updated to any 5.11 kernel API changes, because anybody who
changed a kernel API was required to update your driver for you.

(And no, "We only plan to sell 50,000 so it's not worth it" is not a valid excuse.  There's
plenty of stuff that's in-tree that's very niche with only a few users.  Heck, we kept
an entire architecture (the i386 Voyager) around for 2 machines.  Not two models,
two physical machines.  We finally dropped it when James Bottomley was unable to
mix-and-match parts from the two machines to get either one to boot....)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies