Hi,
尝试按我的理解解释了一下；-）
On 2020/10/20 13:39, Erik Yuan wrote:
Hi Xiuqi,
多谢详尽的解释, 澄清了好些过往的一些错误理解：） 还有点疑问。
On 10/19/2020 3:22 PM, Xie XiuQi wrote:
Hi,
非常感谢参与openEuler kernel 的讨论：
On 2020/10/19 13:37, Erik Yuan wrote:
且，如果主干和分支如果在同一个月都发版本时，有可能引起版本号重复。如都是10月份 第2个版本，则版本号后缀都是 -2010.2.0
- <年月>.<月份内Release号> ，不能体现大版本小版本的层级关系
2 改进方案 （以 5.10 内核为例）
版本号格式：(格式与原方案完全相同，只是各字段含义有细微变化）
5.10.0-<开发版本号>.<维护版本号>.<构建号/buildid>
总体思路：
- 上游版本号选定后，上游版本号保持不变；只更新下层版本号；
诸如 5.10.0 的上游版本号是否还是保持与上游一致？ 反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。
4.19 上，关于 sublevel 版本号，下游有多次混淆和误解这个含义。而且，就在我准备 回这封邮件的时候，又有人找我澄清这个事情。
比如，以 openEuler 20.03 LTS 为例，对应的内核源码版本号是 4.19.90-2003.4.0， 有多个下游团队误以为这个版本是基于 Linux stable 4.19.90 开发的，在进行上游 社区溯源时就会出错，出现不必要的麻烦。而实际上，针对 Linux stable 的补丁， openEuler kernel 是进行 backport 操作，所以在 git log 中，不能说是基于 4.19.90 开发的，4.19.90-2003.4.0 的上游版本并不是 Linux stable 4.19.90。 （通过 git log 可以发现，openEuler 4.19 kernel 的上游版本是 linux stable 的 4.19.13）
c04c050f5bf9 (tag: v4.19.13) Linux 4.19.13
也就是目前从stable同步 4.19.x 后 修改openEuler kernel的sublevel 是与 stable 的x不一致的？ 目前是 openEuler 的sublevel > 主线的sublevel。 之前理解openEuler kernel的sublevel 是对应stable kernel的sublevel。
是一致的。openEuler kernel 回合 4.19.x 的补丁之后，sublevel 就变为 x. 在 4.19 上，实际上是把 stable 中修改 Makefile sublevel 的补丁也backport回来了。
commit 94a531f89cf3c6c40bebee7acab581a8033a5283 (HEAD -> kernel-4.19, origin/kernel-4.19) Author: Greg Kroah-Hartman gregkh@linuxfoundation.org Date: Mon Oct 19 21:23:04 2020 +0800
Linux 4.19.152
Merge 19 patches from 4.19.152 stable branch (22 total) beside 3 already merged patches: 128278f444ab Bluetooth: A2MP: Fix not initializing all members 360f80e34292 Bluetooth: L2CAP: Fix calling sk_filter on non-socket based channel 7b2e80606a5d Bluetooth: MGMT: Fix not checking if BT_HS is enabled
Tested-by: Pavel Machek (CIP) pavel@denx.de Tested-by: Jon Hunter jonathanh@nvidia.com Tested-by: Guenter Roeck linux@roeck-us.net Tested-by: Linux Kernel Functional Testing lkft@linaro.org Link: https://lore.kernel.org/r/20201016090437.301376476@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Yang Yingliang yangyingliang@huawei.com
diff --git a/Makefile b/Makefile index f2c9db9b4015..aa79ce7bfdc7 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 VERSION = 4 PATCHLEVEL = 19 -SUBLEVEL = 151 +SUBLEVEL = 152 EXTRAVERSION = NAME = "People's Front"
那么如果基于新方案，引入 <开发版本>.<维护版本>后，是否可以将sublevel 在某个tag后调整回去与 stable保持一致？ 然后sublevel 只在每次与stable kernel同步后 才更新演进。期间发生的kernel build版本只是变更 <开发版本>?? 这样从openEuler kernel的版本号能比较直观的建立与stable kernel的关系。
我原本也是你说的这个思路，而且 4.19 也是这么做的，完整的合入社区 stable 的版本 4.19.x 之后，sublevel 也改为 x。 是由于前面我提到的一些误解，所以现在想保持 sublevel 不变。 不过，我个人是可以接受 seblevel 与回合的社区 4.19.x 的相同的。 虽然从严格意义上讲，由于已经合入了其他的补丁，openEuler kernel sublevel 的含义与 stable 的有细微的差别， 但确实是能与 stable kernel 建立直观的联系。
有利有弊，对熟悉 kernel 开发的人来说，与 stable kernel 的sublevel建立联系，能帮助我们了解跟踪到了哪个 stable 版本。 对于不熟悉 kernel 开发的人来说，他看到就是一个版本号，他们以为 sublevel 变了，就后面的一切都变了。或者以为你这个 版本的 base 就是 VERSION.PATCHLEVEL.SUBLEVEL。
上面提到的“反映大小版本关系在新方案里面似乎更多的依赖于引入的开发版本号。”， 我确实是这个想法：选择了上游社区的某个版本，之后就是在 openEuler 社区的开发、回合， 保持上游版本号固定，之后就只更新openEuler社区的版本号部分。
版本号是否可以借鉴 一下 suse的，例如 5.3.18-18.21--sle15-sp2
5.3.18-lp152.19.2
之类，通过添加一个dist ver之类的string字段来区分。 是否能解决问题？ 个人觉得openEuler LTS的kernel 还是会不时同步对应的 upstream kernel的，也就是 5.10.x而不是 sublevel 总是0。
openEuler LTS 的 kernel 会定期同步 upstream kernel 的，也就是 5.10 也会定期同步 linux stable 5.10.x 的补丁。 确实是这样的，而且 openEuler 的 4.19 内核，再 backport 对应的 stable 版本之后，也会修改 sublevel。 实际执行过程中，遇到上面的问题。也是我提议改成 sublevel version 保持不变的重要原因。当然，在 backport 时， git log 中会描述补丁来自哪个 stable 版本，在 release note 中也会说明，同步到哪个 stable 版本了。
另外，suse 保留了 sublevel 更新的一个原因，应该与其补丁管理方式有关，suse 使用 quilt 管理补丁，相当于 上游 stable 版本有更新时，做了 rebase 操作，更新 sublevel 顺理成章。
关于你上面提到的 dist ver 之类的 string 字段，我的想法是，5.10 的 版本号规则，在 4.19 上微调，尽量 避免在格式上有大的变动，毕竟 4.19 已经有很多下游在使用了;-）
目前 openEuler的kernel版本号 能区分innovation 和 LTS 么？
openEuler kernel source 的版本号，没有区分 innovation 和 LTS。 我理解应该是看 openEuler 版本的发布时机，来选择采用哪个版本的 openEuler kernel。
按照现在的 LTS 策略，肯定会出现 innovation 和 LTS 都采用 5.10 内核的情况， 但是由于 innovation 和 LTS 发布时机不同，选用内核时，<开发版本> 是不同的。
更极端的情况，innovation 和 LTS 假设选择的内核，<开发版本> 也相同，那也好办， innovation 和 LTS 这时就干脆使用相同版本的内核，包括 Maintenance 号。可能只是 打包时，rpm 包的后缀有区别，oe1 这个字段。
按照目前 LTS 和 innovation 选择 upgrade kernel的策略（都选择Linux LTS)， 可以出现 openEuler 某个LTS 版本选择的 Linux kernel LTS版本 与innovation版本选择的 Linux kernel LTS版本一致的情况。 此时如何区分两个版本所发布的kernel包？ <开发版本> 我理解应该是从属于 VERSION.PATCHLEVEL.SUBLEVEL 下的，而不是整个openEuler 全局编号的。
<开发版本> 是 openEuler kernel 全局的，是在 4.19、5.10 等，每个大版本范围内是全局的， 不是从属 VERSION.PATCHLEVEL.SUBLEVEL， 而是可以理解为从属 VERSION.PATCHLEVEL。 不管 SUBLEVEL 更新还是保持不变，都不应该影响 <开发版本> 的更新。
如果 <开发版本> 从属于 VERSION.PATCHLEVEL.SUBLEVEL 的话，会有问题，就会出现 下面这样的版本号序列，体现不出openEuler kernel 的演进关系，<开发版本> 会经常 reset.
三个思路对比： <从属 sublevel> <sublevel更新,开发版本全局> <sublevel 不更新> 5.10.1-1.0.0 5.10.1-1.0.0 5.10.0-1.0.0 5.10.1-2.0.0 5.10.1-2.0.0 5.10.0-2.0.0 5.10.1-3.0.0 5.10.1-3.0.0 5.10.0-3.0.0 5.10.1-4.0.0 5.10.1-4.0.0 5.10.0-4.0.0 5.10.2-1.0.0 5.10.2-4.0.0 5.10.0-5.0.0 5.10.3-1.0.0 5.10.3-4.0.0 5.10.0-6.0.0 5.10.3-2.0.0 5.10.3-5.0.0 5.10.0-7.0.0
综上，应该是上面 2 3 两个方案里面选择一个，我之前说的是方案3，如果更新 sublevel 的话， 就是方案2。我个人倾向于3，但我能接受2.
谢谢！ Erik
上面是我的观点和理由，再次感谢参与讨论，本周tc上，也看一下大家的意见。
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.