Hi, On August 2, 2022 8:58:47 PM GMT+02:00, Denys Dmytriyenko <[email protected]> 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/YYYY" 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: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
