On Mon, 2022-08-01 at 19:30 +0200, Alexander Kanavin wrote: > 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?
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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1610): https://lists.openembedded.org/g/openembedded-architecture/message/1610 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]] -=-=-=-=-=-=-=-=-=-=-=-
