Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?
Em seg., 1 de ago. de 2022 às 19:41, Richard Purdie < richard.pur...@linuxfoundation.org> 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. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1611): https://lists.openembedded.org/g/openembedded-architecture/message/1611 Mute This Topic: https://lists.openembedded.org/mt/92611044/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?
On Mon, 2022-08-01 at 19:30 +0200, Alexander Kanavin wrote:
> On Mon, 1 Aug 2022 at 13:22, 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
-=-=-=-=-=-=-=-=-=-=-=-
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: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?
Em seg., 1 de ago. de 2022 às 14:30, Alexander Kanavin <
alex.kana...@gmail.com> escreveu:
> On Mon, 1 Aug 2022 at 13:22, 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?
>
I don't see problems with this and whoever wishes to support it, can easily
override it.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1609):
https://lists.openembedded.org/g/openembedded-architecture/message/1609
Mute This Topic: https://lists.openembedded.org/mt/92611044/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?
On Mon, 1 Aug 2022 at 13:22, 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
-=-=-=-=-=-=-=-=-=-=-=-
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: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?
Hi Alex, On 25 Jul 2022, at 19:13, Alexander Kanavin via lists.openembedded.org 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1607): https://lists.openembedded.org/g/openembedded-architecture/message/1607 Mute This Topic: https://lists.openembedded.org/mt/92611044/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
