On Thu, Feb 26, 2026 at 12:49 PM Richard Purdie <[email protected]> wrote: > > On Thu, 2026-02-26 at 12:37 +0100, Nicolas Dechesne via > lists.openembedded.org wrote: > > On Wed, Feb 25, 2026 at 6:44 PM Paul Barker <[email protected]> wrote: > > > I've been briefly discussing stable branch update policy with Yoann. > > > There's a few recipes in openembedded-core which I would like to propose > > > that we always update to the latest version on LTS and stable branches. > > > These are recipes typically providing data that is expected to change > > > over time, with little or no code. > > > > > > You could say ca-certificates is already covered by the fact that > > > security fixes are acceptable for example, but a clearer policy would be > > > better. > > > > > > Any policy change will go to the TSC for approval, the goal here is to > > > get some review and input so that a concrete proposal can be put > > > forward. > > > > > > The recipes that come to my mind are: > > > > > > - ca-certificates: To allow access to HTTPS resources we need to keep > > > these up-to-date. > > > > > > - Keeping this up-to-date is common practice in other distros. > > > > > > - tzdata: To stay up to date with timezone or daylight savings changes. > > > > > > - Debian takes upgrades to this on stable branches > > > (see https://tracker.debian.org/pkg/tzdata). > > > > > > - mobile-broadband-provider-info: To stay up to date with provider > > > changes. > > > > > > - The README file for this project says "The Package contains only > > > informational files so it's safe for distributions to grab updates > > > even during feature freeze and maintenance stages." > > > > > > What opinions do other folks have? > > > > > > Are there any other recipes we should include in this list? > > > > I know this is going to be controversial.. what can we do to keep > > linux-firmware a bit more up-to-date? the recipe in scarthgap has not > > been updated since it was released. Other distros deal with > > linux-firmware in various ways.. > > The challenge is that linux-firmware is a totally different thing.
Correct. And we already discussed that. I am hoping to get more feedback about the overall idea. Or feedback about how others typically use linux-firmware in LTS branches, since not updating it at all seems problematic to me. Other distros manage linux-firmware in different ways. Debian seems to either take full upgrade, or cherry picks specific firmware files upgrade. Ubuntu is stricter and only updates firmware files (or add new files) on-demand, as needed. > > a) We have little idea what the internal changes in the firmware actually mean > > b) The liunx-firmware recipe is complex and changes a lot > > c) The firmware in the codebase has very different properties and > change controls, there is a lot lumped together and QCOM has different > policies and timelines for their changes compared to other vendors who > have firmware there (for exmaple) > > d) The linux-firmware recipe itself has caused all kinds of regressions in > the past > > Yes, we have done a lot to address d) recently but it is far from clear > we would be safe due to the other issues. > > Cheers, > > Richard > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232021): https://lists.openembedded.org/g/openembedded-core/message/232021 Mute This Topic: https://lists.openembedded.org/mt/118010472/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
