Hello,

an idea just popped into my head that I don't remember having been discussed:

Should stable-branch oe-core issue a warning via bitbake when it is
close to EOL and perhaps a stronger warning when it has crossed it?

I feel that this page:
https://wiki.yoctoproject.org/wiki/Releases
is not enough to ensure the message (of not using EOL yocto) reaches
the users, and we need something better and directly seen by anyone
invoking bitbake.

Is it a terrible idea? Awesome idea? Ok-ish idea?

Alex

On 7/25/22 11:13, Alexander Kanavin wrote:

Hello,

an idea just popped into my head that I don't remember having been discussed:

Should stable-branch oe-core issue a warning via bitbake when it is
close to EOL and perhaps a stronger warning when it has crossed it?

I feel that this page:
https://wiki.yoctoproject.org/wiki/Releases
is not enough to ensure the message (of not using EOL yocto) reaches
the users, and we need something better and directly seen by anyone
invoking bitbake.

Is it a terrible idea? Awesome idea? Ok-ish idea?

Only if the warning can be turned off.   I can see it becoming irritating after a while for those branches in long-term maintenance after they EOL.

-armin

Alex

I don't like the idea at all, just because I feel that it will be based on a datetime (or some other criteria) to issue this warning, which will prevent use cases where ppl do a fork and maintain them on their own.

In my opinion everyone should be aware of the lifecycle of the releases published by the project - also as an additional thought it would prevent situations where a hotfix needs to applied to older branches...
Latest occurrences such as the github protocol issue or the backported override syntax makes me feel that issuing a warning might be not the best idea, even if the particular branch has not seen frequent updates.

Still it would come down to either apply a commit to warn on every run or the mentioned datetime criteria - both of them can be tricked/avoided easily - so I don't see the benefit

The benefit is two-fold:

- when EOL point is crossed, and you want to carry on using the
branch, there should be an explicit step of saying 'I know it has
reached EOL and I'm ok with that, and I will take care of security
fixes and ensuring the users of my product aren't exposed to some
latest branded vulnerability with a website and a logo'. That step can
be adding a local.conf tweak or some such.

- simply increasing awareness of the lifecycles, because not
respecting them (out of ignorance, or out of neglect - does not
matter) has product security implications for the whole domain. The
webpage just isn't doing it. And saying 'everyone should be aware'
isn't doing it either.

Alex

On Tue, 26 Jul 2022 at 00:09, Ruslan Bilovol -X (rbilovol -
GLOBALLOGIC INC at Cisco) <rbilovol@...> wrote:

I remember that I proposed a similar idea on one
of pre-covid OEDEM meetings during LTS discussions.

We discussed at least two approaches: date-based
(e.g. after some date bitbake will print the message)
and last-commit based (e.g when maintainer EOLs
the branch his last commit will patch OE so it will
print the message)

As far as I remember we also discussed disadvantages.
For the date-based approach disadvantage was if someone
forks the branch but in mainline maintainer decided to
extend support, he will patch the EOL date in mainline,
but forked branch won't have it and will post annoying
message during the build.
For the last-commit approach, if someone forks the
branch he will never receive that last commit unless
he merges it, and may think the branch is still maintained
while it isn't.

Another idea was to do bitbake online check if the release
is still supported (e.g. bitbake reaches some OE/Yocto servers
online) but that may not work for people who don't use
Internet connection for the build (BB_NO_NETWORK option
is enabled)

There were also some other discussions of that, however
I don't remember any details.

As a bottom line, we discussed it, but didn't have any action plan

Thanks,
Ruslan

________________________________
From: openembedded-architecture@... <openembedded-architecture@...> on behalf of Alexander Kanavin <alex.kanavin@...>
Sent: Monday, July 25, 2022 9:13 PM
To: openembedded-architecture <openembedded-architecture@...>
Subject: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?

Hello,

an idea just popped into my head that I don't remember having been discussed:

Should stable-branch oe-core issue a warning via bitbake when it is
close to EOL and perhaps a stronger warning when it has crossed it?

I feel that this page:
https://wiki.yoctoproject.org/wiki/Releases
is not enough to ensure the message (of not using EOL yocto) reaches
the users, and we need something better and directly seen by anyone
invoking bitbake.

Is it a terrible idea? Awesome idea? Ok-ish idea?

Alex

Hi Alex,

On 25 Jul 2022, at 19:13, Alexander Kanavin via lists.openembedded.org <alex.kanavin=gmail.com@...> wrote:

an idea just popped into my head that I don't remember having been discussed:

Should stable-branch oe-core issue a warning via bitbake when it is
close to EOL and perhaps a stronger warning when it has crossed it?

I feel that this page:
https://wiki.yoctoproject.org/wiki/Releases
is not enough to ensure the message (of not using EOL yocto) reaches
the users, and we need something better and directly seen by anyone
invoking bitbake.

Is it a terrible idea? Awesome idea? Ok-ish idea?

We discussed this in the Yocto TSC last week and this has lots of non-trivial complications.

Would this be something done in oe-core, or something that distros (such as Poky) can opt in to? We don’t want to start warning when oe-core is EOL if the user is using a commercial Yocto release which still has support for many years.

Would this be done with a variable (be it a EOL date, or a marker) in the git repository itself, or something that if fetched periodically? A variable in the git repository would need to be kept up to date, and there’s potentially a significant delay between a change landing in oe-core and reaching a user (oe-core release -> OSV release -> BSP release) which could result in inappropriate warnings. The same information being online and fetched on builds would solve that problem but instead add phone-home issues and the usual network complications (caching, no-network use cases, etc).

Whilst we can see that there are definite value propositions in alerting users that a release is approaching EOL, there are considerable complications to be thought though.

Ross

On Mon, 1 Aug 2022 at 13:22, Ross Burton <Ross.Burton@...> wrote:

Would this be something done in oe-core, or something that distros (such as Poky) can opt in to? We don’t want to start warning when oe-core is EOL if the user is using a commercial Yocto release which still has support for many years.

Would this be done with a variable (be it a EOL date, or a marker) in the git repository itself, or something that if fetched periodically? A variable in the git repository would need to be kept up to date, and there’s potentially a significant delay between a change landing in oe-core and reaching a user (oe-core release -> OSV release -> BSP release) which could result in inappropriate warnings. The same information being online and fetched on builds would solve that problem but instead add phone-home issues and the usual network complications (caching, no-network use cases, etc).

Whilst we can see that there are definite value propositions in alerting users that a release is approaching EOL, there are considerable complications to be thought though.

I think this could work the following way:

- EOL date defined in a variable in meta/conf/distro/end-of-life.inc,
for stable branches only, and with ?=, so it can be easily overriden
by commercial distros or users who know what they are doing.
- if the EOL date is less than (say) 1 month away, bitbake prints a
note. If the EOL date is in the past, it becomes a warning.
- the note or the warning uses guarded language ('may', 'possibly',
etc.) and points to the Releases wiki page and LTS policy pages

Any particular problems with this approach?

Alex

On Mon, 2022-08-01 at 19:30 +0200, Alexander Kanavin wrote:

On Mon, 1 Aug 2022 at 13:22, Ross Burton <Ross.Burton@...> wrote:

Would this be something done in oe-core, or something that distros
(such as Poky) can opt in to? We don’t want to start warning when
oe-core is EOL if the user is using a commercial Yocto release
which still has support for many years.

Would this be done with a variable (be it a EOL date, or a marker)
in the git repository itself, or something that if fetched
periodically? A variable in the git repository would need to be
kept up to date, and there’s potentially a significant delay
between a change landing in oe-core and reaching a user (oe-core
release -> OSV release -> BSP release) which could result in
inappropriate warnings. The same information being online and
fetched on builds would solve that problem but instead add phone-
home issues and the usual network complications (caching, no-
network use cases, etc).

Whilst we can see that there are definite value propositions in
alerting users that a release is approaching EOL, there are
considerable complications to be thought though.

I think this could work the following way:

- EOL date defined in a variable in meta/conf/distro/end-of-life.inc,
for stable branches only, and with ?=, so it can be easily overriden
by commercial distros or users who know what they are doing.
- if the EOL date is less than (say) 1 month away, bitbake prints a
note. If the EOL date is in the past, it becomes a warning.
- the note or the warning uses guarded language ('may', 'possibly',
etc.) and points to the Releases wiki page and LTS policy pages

Any particular problems with this approach?

Taking something like Dunfell where it was originally for two years,
then was extended you could end up with the date not agreeing with the
reality in some checkouts if they weren't updated. There is an issue if
a user isn't updating but even so it isn't great for the project.

There is also a concern that OSVs may forget to override it (or just
not realise they needed to) and the "fires" that would start when the
behaviour of a product changed like this showing warnings to the user
would be significant.

I do feel that whilst well intentioned, there are too many ways it can
go wrong in ways that will cause bad feelings towards the project.

Cheers,

Richard

On 8/2/22 01:01, Otavio Salvador wrote:

Em seg., 1 de ago. de 2022 às 19:41, Richard Purdie <richard.purdie@... <mailto:richard.purdie@...>> escreveu:
I do feel that whilst well intentioned, there are too many ways it can
go wrong in ways that will cause bad feelings towards the project.
What about security flaws that aren't fixed and could lead to a compromised device and people not knowing they were using an EOL release? That will cause bad feelings towards the project as well.
I see a warning isn't perfect but is a better option than users not knowing it is EOL.

We are trying to use technology to solve a social problem. No amount of tweaking the code will stop people from making poor choices.

How can we do a better job of communicating bad practices to the user baser? Do we have a list of products using bad practices? (I realize this is its own can of worms though)

Philip

--
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br <http://www.ossystems.com.br> http://code.ossystems.com.br <http://code.ossystems.com.br>
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

Hi,

On Tue, Aug 02, 2022 at 08:18:46AM +0200, Philip Balister wrote:

We are trying to use technology to solve a social problem. No amount of
tweaking the code will stop people from making poor choices.

How can we do a better job of communicating bad practices to the user baser?
Do we have a list of products using bad practices? (I realize this is its
own can of worms though)

I agree. For those active in the community the LTS and release statuses
are clear but for outsiders not. I can't see the branch and release
status with 2 clicks from https://www.yoctoproject.org/

The latest releases are mentioned but not the maintenance status.

Cheers,

-Mikko

On Mon, Aug 1, 2022 at 11:18 PM Philip Balister <philip@...> wrote:

On 8/2/22 01:01, Otavio Salvador wrote:

Em seg., 1 de ago. de 2022 às 19:41, Richard Purdie
<richard.purdie@...
<mailto:richard.purdie@...>> escreveu:

I do feel that whilst well intentioned, there are too many ways it can
go wrong in ways that will cause bad feelings towards the project.

What about security flaws that aren't fixed and could lead to a
compromised device and people not knowing they were using an EOL
release? That will cause bad feelings towards the project as well.

I see a warning isn't perfect but is a better option than users not
knowing it is EOL.

We are trying to use technology to solve a social problem. No amount of
tweaking the code will stop people from making poor choices.

How can we do a better job of communicating bad practices to the user
baser?

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?

Do we have a list of products using bad practices? (I realize
this is its own can of worms though)

Philip

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br <http://www.ossystems.com.br>
http://code.ossystems.com.br <http://code.ossystems.com.br>
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750

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.

Alex

Greetings,

On 8/2/22 09:33, Mikko Rapeli wrote:

Hi,

On Tue, Aug 02, 2022 at 08:18:46AM +0200, Philip Balister wrote:

We are trying to use technology to solve a social problem. No amount of
tweaking the code will stop people from making poor choices.

How can we do a better job of communicating bad practices to the user baser?
Do we have a list of products using bad practices? (I realize this is its
own can of worms though)

I agree. For those active in the community the LTS and release statuses
are clear but for outsiders not. I can't see the branch and release
status with 2 clicks from https://www.yoctoproject.org/

The latest releases are mentioned but not the maintenance status.

Exactly. I filed a bug about this last year but I don't know how to fix it. In a few words, I'd like to add "Supported until MM/YYYY" to the description of each supported release. This could help people to make a choice.

Does anybody know how to change this on the website?

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

On 8/2/22 10:13, Michael Opdenacker via lists.openembedded.org wrote:

Greetings,

Exactly. I filed a bug about this last year but I don't know how to fix it. In a few words, I'd like to add "Supported until MM/YYYY" to the description of each supported release. This could help people to make a choice.

Does anybody know how to change this on the website?

Oops, forgot the link to the bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14503
Don't hesitate to add your comments directly to Bugzilla.
Thanks
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

On Tue, 2022-08-02 at 10:08 +0200, Alexander Kanavin wrote:

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.

Keep in mind that the LTS are still comparatively new in the timescales
people work within and that we have changed and defined a new policy
comparatively recently. A large portion of this is a social issue as
Philip mentioned and people do pick up and learn that over time. This
isn't the only aspect of the project people need to learn.

I'm not convinced we have to "solve" this problem with technical means.
We do have information out there explaining things and that information
is improving over time (e.g. the EOL notices on the older release
manuals) which was surprisingly difficult and only done embarrassingly
recently. We are also trying our best to have good new features which
offer people a reason to upgrade. This isn't doing nothing.

Cheers,

Richard

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.