Thanks for writing this Qi! The YP TSC discussed this at our last meeting and I think we have a plan on how we can move forward.
On Fri, 2026-05-22 at 05:42 +0000, Chen, Qi wrote: > 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: > https://lists.openembedded.org/g/openembedded-core/message/237197 > https://lists.openembedded.org/g/openembedded-core/message/237201 > > The criteria for adding such settings will follow the consensus we reach > in Topic 2. The TSC has agreed we should backport the core changes to bitbake and oe-core needed to support this, at least for wrynose. The recipe markup information is a little different and needs more discussion and agreement. > 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. This is correct. If we didn't have this policy, you could argue pretty much anything in master should be backported! > 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. In general, exceptions would need TSC review/approval unless it was something simple the maintainers could make a decision on. > 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: > https://lists.openembedded.org/g/openembedded-core/message/237200 > https://lists.openembedded.org/g/openembedded-core/message/237198 > > 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: > https://lists.openembedded.org/g/openembedded-core/message/237199 > https://lists.openembedded.org/g/openembedded-core/message/237201 > I think these are a great start at the criteria needed. What I (and the TSC) would like to see is that we get community consensus around these criteria for adding UPSTREAM_STABLE_RELEASE_REGEX, then document them in our official stable release policy. We can add to the process that the major review/justification/decision needs to happen when the change is proposed for master. Once merged into master, the stable maintainer can backport it as appropriate without further approvals. I therefore plan to merge the base changes to master. The recipe markup needs to be done once we have agreed and put the policy in place. As patches are proposed, we may need to tweak the policy if we find it isn't quite right, again, ideally via community consensus. The TSC is the decision maker if that cannot be reached. Does that work for everyone? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#2383): https://lists.openembedded.org/g/openembedded-architecture/message/2383 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]] -=-=-=-=-=-=-=-=-=-=-=-
