From: "Yoann Congal" <yoann.congal@smile.fr>
To: "Paul Barker" <paul@pbarker.dev>,
"openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>,
"openembedded-architecture@lists.openembedded.org"
<openembedded-architecture@lists.openembedded.org>
Subject: Re: Recipes which should always be upgraded on stable branches
Date: Fri, 06 Mar 2026 11:29:26 +0100 [thread overview]
Message-ID: <DGVMNPT5SAC8.MO37XH41TOW8@smile.fr> (raw)
In-Reply-To: <1e6175f982bbd141fcc156113aa6e798a3120bdc.camel@pbarker.dev>
On Wed Feb 25, 2026 at 6:44 PM CET, Paul Barker wrote:
> Hi all,
>
> 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?
>
> Best regards,
Hello all,
A quick update on this:
The YP TSC discussed and agreed that:
* ca-certificates,
* tzdata,
* wireless-regdb and
* mobile-broadband-provider-info
can be regularly upgraded on stable branches.
So I'll gladly accept those upgrades.
Note that (as Paul noticed) the tzdata 2026a release announcement says
"It also has significant changes to code and to the build procedure.".
So some care will have to taken there...
Regards,
--
Yoann Congal
Smile ECS
prev parent reply other threads:[~2026-03-06 10:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 17:44 Recipes which should always be upgraded on stable branches Paul Barker
2026-02-25 19:04 ` [OE-core] " Ankur Tyagi
2026-02-25 23:50 ` [Openembedded-architecture] " Mark Hatle
2026-02-26 9:24 ` Yoann Congal
2026-02-26 11:37 ` Nicolas Dechesne
2026-02-26 11:49 ` Richard Purdie
2026-02-26 13:10 ` Nicolas Dechesne
2026-02-26 13:58 ` Richard Purdie
2026-04-30 21:37 ` Ricardo Salveti
2026-03-06 10:29 ` Yoann Congal [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DGVMNPT5SAC8.MO37XH41TOW8@smile.fr \
--to=yoann.congal@smile.fr \
--cc=openembedded-architecture@lists.openembedded.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul@pbarker.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox