On Tue, Aug 2, 2022 at 1:08 AM Alexander Kanavin <alex.kanavin@...> wrote:

On Tue, 2 Aug 2022 at 09:58, Andre McCurdy <armccurdy@...> wrote:

Who is the user base you're referring to? The end customer? They don't
see build logs or EOL warnings. The OEM creating releases to add new
features to the boxes in the field? They would see the EOL warnings,
but don't have skills or motivation to update the underlying version
of OE provided to them. The SOC supplier? They make quarterly releases
but follow the OE version defined by the Reference Design Kit they're
using. They would see the EOL warnings but wouldn't be able to do much
about them. The developers of the Reference Design Kit? They have a
road-map of features to work on and updating OE versions isn't much
fun (and they have a point... they are stretched already and their
code is so crufty and brittle that updating OE and being forced into a
newer version of gcc etc is going to cause latent bugs to manifest
themselves, etc. Updating OE and getting the SOC vendors and other 3rd
parties all aligned to it IS a big effort). They would see the EOL
warnings too, but it's not new information. They do update OE versions
every few years (e.g. OE 1.6 -> OE 2.2 -> OE 3.1) but a lot of
deployed boxes have to stay on the older release due to Flash / DRAM
limitations or because of the exorbitant amount the WiFi vendor is
quoting to rebuild and recertify the WiFi driver (ie their headline
announcements of OE updates don't tell the full story). In this kind
of ecosystem, who exactly would benefit from nagging EOL build
warnings?

I tend to agree that warnings popping out of nowhere when the stable
branch is close to (or beyond) EOL is 'too late' - if you got yourself
into that situation, you're likely to have a broader maintainability
problem.

However, I do not agree with the "how can we justify doing nothing at
all" rhetoric I see from people here: I do want to raise awareness of
the lifecycles, and as early as possible for anyone using the project.
So if you say 'this is not going to work', please try to be
constructive and offer alternatives.

Two things which would help users:

- LTS releases (the longer the better) so that users can stick with
an OE version for longer without it becoming EOL. OE 3.1 has been a
huge success in that regard.
- Supporting multiple versions of gcc in each OE release (as
Buildroot does) to allow the upgrade from one OE release to the next
to be broken up into more incremental steps.

If your goal is to educate users who might now be aware of the OE
release cycles then just put a banner such as "This is OE 3.1,
expected to be supported until at least xxx" as the start of every
build. No need to wait until EOL, just tell users up front.