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. 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 (#232003): https://lists.openembedded.org/g/openembedded-core/message/232003 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]] -=-=-=-=-=-=-=-=-=-=-=-
