Hi, My 2 cents.
> 1a) Should patches be backported to released stable branches? Yes, I fully support to have them backported. > 1b) Should part of AUH stable upgrades be done by humans or by a robot? I think the AUH should provide the patches in good shape so are ready for review by a human that can signed them off without much effort. We can study how different components behaved historically and also add more checks during the AUH, like that it doesn’t break any dependency and passes all ptests for the component and the components that depend on it. We could use something like abicheck for the libraries. https://github.com/Nordix/meta-binaryaudit (Disclaimer: we have been updating it from an old version). If it works, it could be part of the yocto project infrastructure. To help with the updates, allowing ptest to be backported could also help on finding issues in the recipe updates or CVE backporting. > 2a) What is a stable version upgrade in OE The alternative on not updating is to do backports and we all know that it is not ideal and we missed security corrections without a vulnerability ID. > 2b) Maintainers can allow exceptions Agree > 2c) Criteria for setting UPSTREAM_STABLE_RELEASE_REGEX I think, in addition we should have an option to update all recipes on the patch version as long as they are known to break things (--try-all? ). Testing and experience should determine if they are candidates to keep updating. But marking the ones that we know are safe is a good step and then the list can grow when we are more confident. Being said that, I'm the first one not to break things on stable branches. Best regards, Daniel From: [email protected] <[email protected]> On Behalf Of Chen Qi via lists.openembedded.org Sent: Friday, 22 May 2026 07:42 To: [email protected] Cc: Richard Purdie <[email protected]>; MacLeod, Randy <[email protected]>; Alexander Kanavin <[email protected]>; Paul Barker <[email protected]>; Khem Raj <[email protected]>; Yoann Congal <[email protected]>; [email protected]; Chen, Qi <[email protected]>; Daniel Turull <[email protected]> Subject: [Openembedded-architecture] Stable version upgrades on OE stable branches Hi All, Recently, we've been doing some work[1][2][3][4] regarding stable version upgrades in OE. I'm sending this email to facilitate discussion and help us reach a consensus before moving forward. There are two main subtopics below, but please feel free to bring up any other related topics. Topic 1: how this will be used on stable branches 1a) Should patches be backported to released stable branches? According to Yocto release schedule[5], wrynose EOL is April 2030, scarthgap EOL is April 2028. Personally, I'd prefer to see wrynose include these changes. @Yoann @Anju what are your thoughts on this? Please note that future changes for recipes like these may be coming: The criteria for adding such settings will follow the consensus we reach in Topic 2. 1b) Should part of AUH stable upgrades be done by humans or by a robot? For successful AUH stable version upgrades, the chance of regression is low. This makes it feasible for a robot to automatically send out AUH upgrades for stable versions. After the patch series passes OEQA, it could be merged. Failed upgrades could then be handled by people interested in upgraing those recipes. Personally, I lean toward having humans handle these upgrades. In my opinion, the action of sending out an upgrade patch is also a promise to fix any further problems or regressions. I think we'll have a problem of people duplicating some work though. Topic 2: determine the criteria for OE stable upgrades 2a) What is a stable version upgrade in OE I recently learnt that OE's policy for stable version upgrades is somewhat different from other distros. As I understand it, the policy allows bug-fix-only upgrades and prohibits new feature, even if they're backward compatible. If my understanding is incorrect, please correct me. 2b) Maintainers can allow exceptions Layer maintainers/stable branch maintainers can allow exceptions to the above "bug-fix-only" policy. A typical example is scarthgap openssl upgrade (3.2.6 -> 3.5.5). Again, please correct me if I've misunderstood. 2c) Criteria for setting UPSTREAM_STABLE_RELEASE_REGEX Setting this variable for a recipe means we can be sure that some certain upgrades are stable version upgrades under OE's criteria. AUH will then upgrade recipes with this variable set for stable releases. Note: This does not mean recipes without this variable cannot be upgraded for stable releases. They simply won't be picked up by AUH. Alex suggested looking at upstream repos' stable branches as a criteria to determine if we can set this variable for a recipe. Examples: I'd like to propose the following standard: 1. Upstream stable branches exist If a recipe's upstream repo has stable branches named with a stable version component, it should be considered reliable criteira for stable version upgrades, and we can set this variable for it. For example, util-linux's version is 2.41.3. There are three parts in the version. And util-linux has branches like origin/stable/v2.41. There are two parts (2.41) in the branch. In this case, we can confidently set UPSTREAM_STABLE_RELEASE_REGEX for it. 2. Upstream maintainer confirmation If the upstream project's maintainer confirms that a bump in some part of the version is bug fix only, we can set this variable. 3. Clear historical or common-sense evidence If a project's change history shows clearly that some kind of version bump is bug fix only, or it's just common sense that some kind of version bump is bug fix only, then we can set this variable for the recipe. kmod and openssh are two such examples: That's all from me for now. I look forward to our discussion and hope we can reach a consensus. Best regards, Qi
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2357): https://lists.openembedded.org/g/openembedded-architecture/message/2357 Mute This Topic: https://lists.openembedded.org/mt/119437109/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
