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:
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.
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:
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
That's all from me for now. I look forward to our discussion and hope we can
reach a consensus.
[1] oe-core changes:
https://lists.openembedded.org/g/openembedded-core/message/237195
[2] bitbake changes:
https://lists.openembedded.org/g/bitbake-devel/message/19501
[3] devtool changelog change:
https://lists.openembedded.org/g/openembedded-core/message/237247
[4] AUH change: https://lists.yoctoproject.org/g/yocto-patches/message/3930
[5] Yocto Release Schedule: https://wiki.yoctoproject.org/wiki/Releases
Best regards,
Qi
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#2356):
https://lists.openembedded.org/g/openembedded-architecture/message/2356
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]]
-=-=-=-=-=-=-=-=-=-=-=-
