On Mon, 1 Aug 2022 at 13:22, Ross Burton <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1608):
https://lists.openembedded.org/g/openembedded-architecture/message/1608
Mute This Topic: https://lists.openembedded.org/mt/92611044/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
