On Tue, Aug 2, 2022 at 1:08 AM Alexander Kanavin <[email protected]> wrote: > > On Tue, 2 Aug 2022 at 09:58, Andre McCurdy <[email protected]> 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: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
