Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?

[Quentin Schulz]

Hi,

On August 2, 2022 8:58:47 PM GMT+02:00, Denys Dmytriyenko  
wrote:
>On Tue, Aug 02, 2022 at 10:13:11AM +0200, Michael Opdenacker via 
>lists.openembedded.org wrote:
>> 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/" 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?
>
>I usually google "yocto releases" and the first result is what you need (all 
>the maintenance and EOL details):
>
>https://wiki.yoctoproject.org/wiki/Releases
>

Just chiming in quickly.

IMO using Dunfell 3.1.10 is as bad as using Honister 3.4.4. Even though we say 
Dunfell is an LTS, its the branch that is, not the tag. The point would be to 
say when a *tag* is EOL. And that is usually 2 or 3 months max after last 
release of the same series. This would fix the issue of releases being 
supported longer than initially announces. The EOL date would be added at the 
same time as the tag. Master would never see this warning (or have year 2100) 
since it's useless.

The warning needs to be possibly disabled otherwise PCs with incorrect dates (I 
could imagine an air-gaped PC doing offline builds for example) (or disable the 
warning if the build is offline for example).

I don't believe companies providing extended support for EOL releases keep 
their poky/oe-core git repo untouched, so they can very well change this 
variable themselves directly in the code. That's not a reason to make this 
silenceable?

In the end, considering how few companies actually care about using a somewhat 
recent version of the Linux kernel, and how vocal the upstream community is 
about how bad a practice that is, I don't see how the Yocto Project would 
manage to educate their users better than the kernel community tries?

However, I agree that making the Releases page of the wiki much more accessible 
is a good thing (e.g. an obvious place somewhere on yoctoproject.org directly).

I wish I had more to suggest or add to the topic but that is all I have right 
now.

Here is to hoping this was not just noise,
Cheers,
Quentin

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1624): 
https://lists.openembedded.org/g/openembedded-architecture/message/1624
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?

[Denys Dmytriyenko]

On Tue, Aug 02, 2022 at 10:13:11AM +0200, Michael Opdenacker via 
lists.openembedded.org wrote:
> 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/" 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?

I usually google "yocto releases" and the first result is what you need (all 
the maintenance and EOL details):

https://wiki.yoctoproject.org/wiki/Releases

-- 
Denys

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1621): 
https://lists.openembedded.org/g/openembedded-architecture/message/1621
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?

[Alexander Kanavin]

On Tue, 2 Aug 2022 at 10:28, Andre McCurdy  wrote:

> 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.

I'm reluctant to add even more things to the banner, there more you
have there, the more it becomes 'noise'. But we can have a link to the
releases wiki and the lifecycle policy in it, that does not require
maintenance.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1620): 
https://lists.openembedded.org/g/openembedded-architecture/message/1620
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?

[Andre McCurdy]

On Tue, Aug 2, 2022 at 1:08 AM Alexander Kanavin  wrote:
>
> On Tue, 2 Aug 2022 at 09:58, Andre McCurdy  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.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1619): 
https://lists.openembedded.org/g/openembedded-architecture/message/1619
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?

[Richard Purdie]

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





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1618): 
https://lists.openembedded.org/g/openembedded-architecture/message/1618
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?

[Michael Opdenacker via lists.openembedded.org]

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/" 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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1617): 
https://lists.openembedded.org/g/openembedded-architecture/message/1617
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?

[Michael Opdenacker via lists.openembedded.org]

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/" 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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1616): 
https://lists.openembedded.org/g/openembedded-architecture/message/1616
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?

[Alexander Kanavin]

On Tue, 2 Aug 2022 at 09:58, Andre McCurdy  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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1615): 
https://lists.openembedded.org/g/openembedded-architecture/message/1615
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?

[Andre McCurdy]

On Mon, Aug 1, 2022 at 11:18 PM Philip Balister  wrote:
>
> On 8/2/22 01:01, Otavio Salvador wrote:
> >
> > Em seg., 1 de ago. de 2022 às 19:41, 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://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 (#1614): 
https://lists.openembedded.org/g/openembedded-architecture/message/1614
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?

[Mikko Rapeli]

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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1613): 
https://lists.openembedded.org/g/openembedded-architecture/message/1613
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?

[Philip Balister]

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



Em seg., 1 de ago. de 2022 às 19:41, 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://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 (#1612): 
https://lists.openembedded.org/g/openembedded-architecture/message/1612
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?

[Otavio Salvador]

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?

[Richard Purdie]

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?

[Otavio Salvador]

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?

[Alexander Kanavin]

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?

[Ross Burton]

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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Openembedded-architecture] should oe-core issue a warning when it reaches EOL?

[Ruslan Bilovol via lists.openembedded.org]

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@lists.openembedded.org 
 on behalf of Alexander 
Kanavin 
Sent: Monday, July 25, 2022 9:13 PM
To: 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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1598): 
https://lists.openembedded.org/g/openembedded-architecture/message/1598
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?

[Konrad Weihmann]

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


On 25.07.22 20: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?

Alex






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1596): 
https://lists.openembedded.org/g/openembedded-architecture/message/1596
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?

[Otavio Salvador]

Em seg., 25 de jul. de 2022 às 15:13, Alexander Kanavin <
alex.kana...@gmail.com> escreveu:

> 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?
>

I like the idea so users are aware of 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 (#1594): 
https://lists.openembedded.org/g/openembedded-architecture/message/1594
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]
-=-=-=-=-=-=-=-=-=-=-=-