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