- Tc - mailweb.openeuler.org

【会议纪要】 RE: 【Meeting Notice】【议题收集】openEuler TC例会 Time: 2020-10-21 10:00-12:00
by Zhanghailiang 21 Oct '20

21 Oct '20

议题1. 升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致 --- xiasenlin 会议纪要： 1) TC无法根据当前提供信息决定gcc是否升级，gcc组件升级由编译器sig分析决定 2) 针对firefox 79.0的CVE漏洞，需要升级到更高版本firefox修复的问题，优先采用openeuler发布版本中gcc 7.3版本编译高版本firefox修复，另外可以选择同时保留gcc 7.3版本和gcc 9.3版本，但是要确保两个gcc版本共存不相互影响 3）长远规划需要考虑openeuler上支持的浏览器情况，如果firefox存在大量漏洞，需要考虑用其他浏览器替换议题2. openEuler kernel 5.10 内核版本号改进方案 -- 谢秀奇会议纪要： 1) 整体上同意版本号改进方案。可以社区发文解释一下，特别是《stable版本号》是否更新，多征求下意见。也可以在summit中做一次讨论。议题3. UKUI SIG、HA SIG 和 ovirt SIG工作进展，以及未来的工作规划汇报（麒麟）会议纪要： 1) 请UKUI, HA, oVirt SIG组和release management SIG沟通，明确版本节奏。 2) 请release SIG组依照反馈的意见，改进release的发布模式，沟通模式，诸如版本时间roadmap, 组件升级情况，版本各阶段时间点等信息汇总到openeuler各sig组员可见的地方，同时要主动和各个SIG组进行协调，不能只依赖SIG组的主动上报议题4. GCC社区版本规划 --郭歌，张海建会议纪要： 1）同意gcc升级策略，会后需要将gcc升级规则文字和图片描述清楚，发布在openEuler博客中，并且在Compiler SIG首页注明gcc roadmap 议题5.关于openEuler 集成的衰退软件的处理建议 --李次华会议纪要： 1）软件退出细则大家基于PR 讨论： https://gitee.com/openeuler/community/pulls/1171 2）在软件引入与退出是宽进严出原则，软件包转移到recycle-sig 后，会继续向外发布，并且告知下游使用风险，执行删除时采取TC 委员投票方式决策 3）部分关键软件上游停止维护的自建仓维护是合理的，为了方便其他国家参与，在github 建仓，在gitee上建立mirror From: Zhanghailiang [mailto:zhang.zhanghailiang@huawei.com] Sent: Wednesday, October 21, 2020 8:54 AM To: tc(a)openeuler.org Cc: douyan(a)kylinos.cn; 侯健 <hj19870806(a)163.com>; yangzhao1(a)kylinos.cn; jiangxinyu(a)kylinos.cn; Xiexiuqi <xiexiuqi(a)huawei.com>; xiasenlin <xiasenlin1(a)huawei.com> Subject: [Tc] 【今日议题】 RE: 【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00 1）升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致 --- xiasenlin 2）议题申报：openEuler kernel 5.10 内核版本号改进方案 -- 谢秀奇 3）UKUI SIG、HA SIG 和 ovirt SIG工作进展，以及未来的工作规划汇报（麒麟） From: Meeting Book [mailto:uMeeting@huawei.com] Sent: Monday, October 19, 2020 8:59 AM To: tc(a)openeuler.org<mailto:tc@openeuler.org> Subject: [Tc] 【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00 Topic 【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time 2020-10-21 10:00-12:00((UTC+08:00)Beijing) Join Conference Join (External) >><https://welink-meeting.zoom.us/j/448457115> Meeting ID 448 457 115 Convener 张海亮 Tips: Dial the access number to join conference<http://app.huawei.com/eshare/voiceMeetings> 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载<https://zoom.us/download> If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download<https://zoom.us/download>

1 0

【Meeting Notice】sig-ai-bigdata regular meeting Time: 2020-10-22 18:30-19:30
by Hubble_Zhu 21 Oct '20

21 Oct '20

Topic sig-ai-bigdata regular meeting Time 2020-10-22 18:30-19:30((UTC+08:00)Beijing)   Join Conference Join (External) >> Meeting ID 595 278 462   Convener Hubble_Zhu   Agenda 1、sig成员前期工作审视 2、下一步计划与分工   Tips: Dial the access number to join conference 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载 If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download

1 0

Re: TC 议题申报：openEuler kernel 5.10 内核版本号规则改进方案
by Xie XiuQi 21 Oct '20

21 Oct '20

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.10 > openEuler 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。 > > 因此，我建议， > 1) <开发版本号> 是基于某个开发主分支来进行全局编号，而不是基于 <stable版本号>; 开发主分支之间的区分通过dist release来区分？是全局的。 > 2) 同一开发主分支所派生的下游分支，<开发版本号> 不是按主分支出版本的时间先后来定义，可以考虑将<开发版本号> 以一定的步长来划分不同的编号区间，譬如 0~ 9999, 10000 ~ 19999, ..... 每个步长 10000. > 目前我们是有3个SP, 谁知道以后有多少个SP？ > 3) <stable版本号>中的 X.Y.Z 的Z，其实在当前的新版本号方案中，没有什么作用，不直接用于区分源分支。保持与 kernel社区一致应该可以接受，能直观反映于上游的关系。 > > > Cheers, > Erik > > > -----Original Message----- > From: Xie XiuQi <xiexiuqi(a)huawei.com> > Sent: Tuesday, October 20, 2020 3:06 PM > To: Erik Yuan <Erik.Yuan(a)arm.com> > Cc: tc <tc(a)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(a)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(a)denx.de> > Tested-by: Jon Hunter <jonathanh(a)nvidia.com> > Tested-by: Guenter Roeck <linux(a)roeck-us.net> > Tested-by: Linux Kernel Functional Testing <lkft(a)linaro.org> > Link: https://lore.kernel.org/r/20201016090437.301376476@linuxfoundation.org > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > Signed-off-by: Yang Yingliang <yangyingliang(a)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.

2 2

【今日议题】 RE: 【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00
by Zhanghailiang 21 Oct '20

21 Oct '20

1）升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致 --- xiasenlin 2）议题申报：openEuler kernel 5.10 内核版本号改进方案 -- 谢秀奇 3）UKUI SIG、HA SIG 和 ovirt SIG工作进展，以及未来的工作规划汇报（麒麟） From: Meeting Book [mailto:uMeeting@huawei.com] Sent: Monday, October 19, 2020 8:59 AM To: tc(a)openeuler.org Subject: [Tc] 【Meeting Notice】【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time: 2020-10-21 10:00-12:00 Topic 【议题收集】openEuler TC例会 (可直接回复此邮件申报议题） Time 2020-10-21 10:00-12:00((UTC+08:00)Beijing) Join Conference Join (External) >><https://welink-meeting.zoom.us/j/448457115> Meeting ID 448 457 115 Convener 张海亮 Tips: Dial the access number to join conference<http://app.huawei.com/eshare/voiceMeetings> 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载<https://zoom.us/download> If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download<https://zoom.us/download>

1 0

TC 议题申报：openEuler 社区关于上游停止维护或衰退软件处理建议
by Licihua 21 Oct '20

21 Oct '20

背景：经抽查openEuler LTS 范围内的900+ 软件，发现其中200+ 软件2年内未发布新版本，80+ 软件上游社区半年内未处理Issue 与PR，18款软件为2010 年前发布，30款软件为2015 年前发布；为了保证openEuler 集成软件质量，针对上游宣布停止维护或实际停止维护软件需要考虑如何保证质量，保证客户持续的高质量体验。处理建议： 1、软件引入时增加社区状态检查： 1、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的，不建议引入， 2、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，但是半年以上未响应的，不建议引入， 3、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，半年以上未响应或者答复停止维护的，不建议引入。 2、增加软件退出规则：当满足以下两个条件时，openEuler软件包的退出申请可以被立即执行，对应repo将从项目中直接删除。 1、软件的License 或出口管制策略影响了目前正在使用的版本，导致openEuler存在商务或者法务上的风险，不能继续集成该软件 2、存在恶意代码或严重安全隐患且openEuler 社区无能力修复的，要求软件被立即移除。除以上描述两种场景外，剩下的场景openEuler对软件包的退出实行过程化管理： 1、随着技术演进与发展，软件因技术陈旧或架构落后，不能满足现有的应用场景被其他更优秀的软件所取代。 2、软件新版本License 或出口管制策略变化导致openEuler 不能集成，openEuler 已经集成的旧版本过于老旧。 3、软件来自知名社区或组织，社区或组织通过发布公告、修改软件仓库状态、将仓库放到特定目录下等方式告知停止维护的。 4、软件来自个人、小型社区或组织，两年内未发布版本（含正式版本与测试版本），无明确版本计划，社区提交了有效的Bug或PR，社区半年以上未响应的。 5、社区运营状态不明确，通过Issue 或者邮件等方式询问社区是否继续维护，社区半年以上未响应或者答复停止维护的。如果软件满足退出条件，但是因openEuler 社区其他软件存在依赖且短时间不能解除或者下游切换周期过长而不能立即退出的，可以由依赖方所在SIG 或原SIG在github 上建立仓库自行维护。 3、增加自维护策略：开源软件符合退出条件，但是因上下游切换周期长，短时间不能退出的，由依赖方SIG或者本SIG 自建仓维护，具体原则如下： 1、知名社区或组织宣布停止维护、License 变化或出口管制原因导致不能集成新版本的，短期内由软件所在 SIG 建立的github 项目维护，并且寻找替代软件，推动上下游尽快切换。 2、个人、小型社区或组织投入不足的，优先联系社区maintainer，传递openEuler 参与贡献的意愿，重新激活上游社区。maintainer 不响应的，需要将软件迁移到openEuler SIG 在github 建立的项目下，由openEuler SIG维护。迁移后需要在原始上游社区发布openEuler SIG继续维护软件的通知，吸引社区其他参与者成为贡献者。 4、增加自维护质量要求： 1、运行在数据面^1的关键软件（例如glibc、dpdk），或者运行在控制面^2/管理面^3，但是可能导致下游客户出现现网事故的（例如升级相关软件dnf）或暴露攻击面的软件（例如网络服务 vsftpd）， 2、需要梳理特性应用场景、规格、使用约束与限制；梳理代码关键流程、开展代码检视工作；补充特性测试、组织各类专项测试、安全/韧性测试、开展薄弱特性质量改进工作。 3、运行在控制面^2/管理面^3，但是常驻系统或高频执行的软件（systemd、sshd)，需要梳理特性应用场景、规格、使用约束和限制，结合特性使用场景开展代码检视；结合特性使用场景补充测试、开展各类专项测试、薄弱质量改进工作。 4、运行在管理面^3且使用频率低，应用场景稳定的（例如anaconda，dconf），通过问题触发方式熟悉代码流程，开展专项测试。 5、不在客户现网环境运行或不影响客户现网运行的软件（如CUnit、Make、gdb），在openEuler 制品仓中维护，基于开源测试代码展开测试活动，定期从友商社区（例如fedora、openSuse）同步补丁代码。原文PR 如下：https://gitee.com/openeuler/community/pulls/1171/files 欢迎各位发表意见李次华欧拉部-2012 实验室华为技术有限公司 Tel : +86 15158056404 Email : licihua(a)huawei.com [cid:image003.png@01D6A6CC.5CE72640] This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

4 3

TC 议题申报：openEuler kernel 5.10 内核版本号规则改进方案
by Xie XiuQi 20 Oct '20

20 Oct '20

海亮 & TC，议题申报：openEuler kernel 5.10 内核版本号改进方案（总体方案和 RHEL/CentOS kernel 版本号规则类似） 1. openEuler kernel 版本号，原方案及存在的问题（以 4.19 为例）版本号格式： 4.19.<stable 版本号>-<年月>.<月份内Release号>.<buildid> 说明： - <stable 版本号>，linux stable 分支版本，合入对应的stable 版本时更新如 4.19.90， 4.19.128 等等 - <年月>，标识版本发布时的年份&月份，如 2010 表示2020年10月份，2009 表示20年9月份 - <月份内Release号>，标识本月内发布的第几个版本，比如 2020年10月份发的第2个版本，则版本号为 xxxx-2020.2.0 - buildid, 构建号，不管是代码还是制品仓，只要有修改要出rpm包，就在之前基础上 +1 存在的问题： - 上述方案，如果只有一条分支，则问题不大，版本号顺序增加 - 如果有多个分支，则可能存在分之间版本号混淆，不能体现主干与分支的关系等问题 - 比如，主干在开发时，<stable 版本号>.<年月>.<月份内Release号> 这几个版本号都在变化；openEuler发布后，<年月>.<月份内Release号> 这几个版本号也都在更新，且，如果主干和分支如果在同一个月都发版本时，有可能引起版本号重复。如都是10月份第2个版本，则版本号后缀都是 -2010.2.0 - <年月>.<月份内Release号> ，不能体现大版本小版本的层级关系 2 改进方案（以 5.10 内核为例）版本号格式：(格式与原方案完全相同，只是各字段含义有细微变化） 5.10.0-<开发版本号>.<维护版本号>.<构建号/buildid> 总体思路： - 上游版本号选定后，上游版本号保持不变；只更新下层版本号； - 社区 5.10.0 是开发分支的上游，选定后，保持不变；开发分支有更新，只升级<开发版本号> - 开发分支是维护分支的上游，一旦选定某个开发版本，转维护时，只升级<维护版本号> - 通过<开发版本号>和<维护版本号>，体现开发与维护的关系 - 主干开发与多个维护分支共同存在时，版本号不混淆，能清晰体现上下游关系各字段具体说明： 1） 5.10.0 前面的基础版本号不变，一直是 5.10.0，不体现 stable 的小版本号； 2）后面几位是 <开发版本号>-<维护版本号>-<构建号/buildid> 比如：5.10.0-2.0.0.0007.oe1.aarch64 %global upstream_version 5.10 %global upstream_sublevel 0 %global devel_release 2 %global maintenance_release .0.0 %global buildid .0007 3）版本号思路： - 开发的时候，只更新<开发版本号>，<维护版本号>保持为 .0.0 - openEuler 发行版发布之后，只更新<维护版本号>，<开发版本号>固定不变 - <构建号/buildid>，构建号，不管是代码还是制品仓，只要有修改要出rpm包，就在之前基础上 +1 4）例子： - 开发的时候，只更新<开发版本号>，维护版本号保持为 .0.0 源码 tag: 5.10.0-1.0.0，制品仓 release: 5.10.0-1.0.0.0001.oe1.aarch64 源码 tag: 5.10.0-2.0.0，制品仓 release: 5.10.0-2.0.0.0002.oe1.aarch64 源码 tag: 5.10.0-3.0.0，制品仓 release: 5.10.0-3.0.0.0003.oe1.aarch64 - openEuler 发行版发布之后，假设从 5.10.0-123.0.0 开发版本转 openEuler 发布，之后再合入维护补丁，就只更新维护版本号（最后那个 0 预留，紧急情况下使用）源码 tag: 5.10.0-123.1.0 制品仓 release: 5.10.0-123.1.0.0041.oe1.aarch64 源码 tag: 5.10.0-123.2.0 制品仓 release: 5.10.0-123.2.0.0042.oe1.aarch64 源码 tag: 5.10.0-123.3.0 制品仓 release: 5.10.0-123.3.0.0043.oe1.aarch64 。。。 - 假设后续有 SP 版本从 5.10.0-456.0.0 开发版本发布，之后再合入维护补丁，就只更新<维护版本号> 源码 tag: 5.10.0-456.1.0 源码 tag: 5.10.0-456.2.0 源码 tag: 5.10.0-456.3.0 。。。 - 开发分支上回合 stable 补丁时，也是只更新<开发版本号> 5）相比之前的好处：相比之前通过月份来定版本号的好处，通过区分开发版本号，和维护版本号，体现主干和和维护分支的关系。之前月份命名版本号，在分支多的情况下，存在混淆的情况，比如，相同月份不同分支的 release 号可能会重复，比如都是10月份的第一个版本：-2010.1.0 3. 影响

4 9

【议题收集】【Meeting Notice】openEuler kernel sig meeting Time: 2020-10-16 10:00-12:00
by Xie XiuQi 20 Oct '20

20 Oct '20

openEuler kernel sig meeting 定于 2020-10-16 10:00-12:00 召开，欢迎回复邮件申报议题。 --- 会议信息 --- 会议链接：https://zoom.us/j/94156903933 会议 ID : 94156903933 --- 会议纪要归档 --- Meeting Record 20200918： https://gitee.com/openeuler/kernel/issues/I1WGN0

1 3

TC议题申报：openEuler社区gcc编译器版本计划
by guoge (A) 19 Oct '20

19 Oct '20

Hi, tc team 申请议题讨论：openEuler社区gcc编译器版本计划该讨论将决定未来每个openEuler版本中支持的gcc编译器版本，由于gcc属于基础设置，版本变动影响面较大，所以gcc版本选型的原则首先是稳定，其次才是新功能目前初步方案如下： 1． gcc一年升级一个大版本，在每年下半年的openEuler创新版本中引入，并维护一年到下一年度上半年的openEuler版本，例如在openEuler 20.09版本中引入gcc 9，并持续维护到openEuler 21.03版本 2．每次升级会选取最新gcc大版本的.3版本作为稳定版本，例如认为gcc 10.1和gcc 10.2不是稳定版本，gcc 10.3是稳定版本，由于2020.9最新的gcc大版本是gcc 9和gcc 10，且gcc 9有9.3版本，gcc 10只有10.2版本，所以选择9.3作为稳定版本 3．每一个gcc大版本只会选择.3作为稳定版本，不升级，有问题或需求采用backport模式，例如openEuler 20.09和21.03都采用gcc 9.3，不会升级到gcc 9.4 具体计划如下： [cid:image001.png@01D6A61E.88FE5F90] 材料见附件

2 1

会议纪要 //回复：【Meeting Notice】sig-high-performance-network regular meeting Time: 2020-10-15 19:00-20:00
by Peanut_Huang 19 Oct '20

19 Oct '20

与会人：Mr.lu, hubble_zhu, peanut_huang, gao_xiingwang, yuan_xin, xu_changye 【会议纪要】前期进展： 1. polycube框架已经成功在openEuler上运行，相关修改等待合入社区 -- liu_xin 2. 将polycube相关工具包推到openEuler上     swagger-codegen已在本地成功构建和运行，待提交合入社区 -- peanut_huang     pyang-swagger依赖pyang，正在验证pyang的构建 -- gao_xiingwang 下一步计划： 1. 建议尽快将polycube相关工具包推到openEuler上     pyang-swagger、pyang -- gao_xiingwang     polycube-codegen   -- peanut_huang     xdp-tools        -- hubble_zhu 2. 建议补充部分高性能网络sig的愿景材料 -- Mr.lu ------------------ 原始邮件 ------------------ 发件人: "Peanut_Huang" <hlm3280(a)qq.com>gt;; 发送时间: 2020年10月14日(星期三) 晚上7:25 收件人: "high-performance-network"<high-performance-network(a)openeuler.org>gt;;"tc"<tc(a)openeuler.org>gt;;"dev"<dev(a)openeuler.org>gt;; 主题: 【Meeting Notice】sig-high-performance-network regular meeting Time: 2020-10-15 19:00-20:00 Topic sig-high-performance-network regular meeting Time 2020-10-15 19:00-20:00((UTC+08:00)Beijing)   Join Conference Join (External) >> Meeting ID 985 033 429   Convener Peanut_Huang Agenda 1.sig成员前期工作审视 2.下一步工作和计划 Tips: Dial the access number to join conference 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 如果加入会议提示“会议已结束或会议号不存在”，请在官网下载最新版本入会。立即下载 If a message is displayed, indicating that the meeting has ended or the meeting ID does not exist, download the latest meeting client and try again.Download

1 0

【议题申报】为满足SP1版本新特性，申请升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致
by xiasenlin 19 Oct '20

19 Oct '20

Hi，Xiuqi 和各位 TC 委员，当前在升级 openEuler:20.03:LTS:Next工程的单包firefox以解决CVE问题时，发现依赖高版本的gcc（9.3）, 与责任人郭歌沟通后，申请增加一个议题：升级openEuler:20.03:LTS:Next 分支的gcc，与20.09版本一致，希望与 TC 委员们和社区成员讨论。附件为原因分析。谢谢。 ——夏森林

7 7

2024

2023

2022

2021

2020

2019

Tc