Hi，
我发现我们理解有不一致的地方，我在下面画个图澄清一下。看一下我有没有解释清楚。
另外，看到你邮件里面有一个保密声明，因为是社区公开讨论，没有保密信息。 你后面把这个声明去掉吧，避免引起不必要的麻烦。
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.
On 2020/10/20 16:51, Erik Yuan wrote:
Hi,
基于之前的讨论，我搞了下面的图。 希望没有将问题复杂化:(
没有复杂化，你发了这个图，讨论更清晰了。我发现我们理解有不一致的地方，我画个图澄清一下。 看一下我有没有解释清楚。
你看一下这个图能解释你的疑问吗?
目前openEuler kernel的分支 与 上游社区的 kerenl分支的大概层次关系是：
5.10.9 5.10.10 5.10.30 5.10.40 5.10.50上游某个LTS 5.10.Z -----*-------*--------------*----------------------- *-----------------------------*-------------------------------------------------> Pull | | | | V V V V openEuler xx.03 LTS(所谓开发主分支) *----p---p----*----p------p----------*----p---*-------------------*------p------------*----p----------------------> 5.10.10-1.0.05.10.10-2.0.0 | 5.10.10-4.0.05.10.10-6.0.0 | | | V V xx.03 LTS SPn(派生分支) *-----p-------p-----*---------p-------------------*-------------------------------------> 5.10.10-3.0.0 5.10.10-5.0.05.10.10-7.0.0
5.10.10openEuler xx.09 inno(独立开发主分支) *------------------------*-----------------------*---------------------------------------> 5.10.10-?.0.05.10.30-?.0.05.10.40-?.0.0
这里考虑引入 <stable版本号> -<开发版本号>.<维护版本号>.<构建号/buildid> 的目的之一是 ‘体现主干与分支的关系’。 但有几个问题： 1） 目前 LTS SP?拉出分支后，原来 LTS第一个版本（标记为SP0）是否还出kernel RPM？ 我理解的还是要出的。 那么是否出现上图的版本编号？
要出 RPM，参考上图，SP0 也是一样，分支拉出来，后续就只更新 Maintenance 号，不存在号码段的问题。
这样单纯从kernel版本号似乎也不好直接区分出来是 来自开发主分支 还是 SPn分支的。 除非<开发版本号>采用 3k + n(n=1对应SP1)的方式。 2） 假如某个innovation版本选择的<stable版本号> 与 某个 LTS版本选择的一样（上游同源)， 基于<开发版本号> 是 从属于5.10.Z 的， 那岂不是也得于 该 LTS版本的<开发版本号> 进行统一编号？ 但这个编号同样的不好直接区分该版本是来源于哪个分支。 编译生成RPM后，会归到不同的 openEuler release 库中，即便RPM包的版本号都是 5.10.10-?.0.0 在多个openEuler 的package repo中出现，还是能从目录path能区分出来。但是在 OBS中看到的tarball包 的版本号 都是 5.10.10-?.0.0， 这个是否容易犯错？ 如果能做到从版本号 能直观的区分是来自哪个branch，对后续可能的程序检查等处理的引入会方便的多。
版本号如果相同，就能确定是使用相同的源码，即 git 库中相同的 tag。
因此，我建议，
- <开发版本号> 是基于某个开发主分支 来进行全局编号，而不是基于 <stable版本号>; 开发主分支之间的区分通过dist release来区分？
是全局的。
- 同一开发主分支所派生的下游分支，<开发版本号> 不是按主分支出版本的时间先后来定义，可以考虑将<开发版本号> 以一定的步长来划分不同的编号区间，譬如 0~ 9999, 10000 ~ 19999, ..... 每个步长 10000.
目前我们是有3个SP, 谁知道以后有多少个SP？ 3) <stable版本号>中的 X.Y.Z 的Z，其实在当前的新版本号方案中，没有什么作用，不直接用于区分源分支。 保持与 kernel社区一致应该可以接受，能直观反映于 上游的关系。
Cheers, Erik
-----Original Message----- From: Xie XiuQi xiexiuqi@huawei.com Sent: Tuesday, October 20, 2020 3:06 PM To: Erik Yuan Erik.Yuan@arm.com Cc: tc tc@openeuler.org Subject: Re: [Tc] TC 议题申报：openEuler kernel 5.10 内核版本号规则改进方案
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.
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.
