openEuler 社区 2021 年 3 月运作报告

在众多同学的共同努力下，openEuler 21.03 创新版本按时发布。正如 openEuler 的定位，我们通过创新推动操作系统演进，又通过版本让技术对用户真正可获得。

在创新方面，华为作为 openEuler 社区的重要贡献者，也是 Linux 5.10 最大的贡献者。openEuler 21.03 第一次集成了 Linux 5.10 内核，也顺理成章。这次升级带来超过 20 多项可见的性能与功能提升。而在主线内核之外，21.03 还进一步集成了内核热升级，分级内存管理，增强的轻量虚拟运行时等技术。

在版本方面，感谢来自华为、麒麟软件和联通的众多开发者的努力，openEuler 21.03 集成了 openStack Victoria（此处尤其感谢 @huangtianhua^[1] ），Kubernetes 1.20，以及基于 pacemaker 和 DRBD 的高可用软件栈解决方案。

社区将在后续的一段时间里组织 meetup 活动，给大家详细介绍这些技术在业务环境中的使用方法和能带来的收益。敬请关注。

新成立 SIG 介绍

2 月 27 日成立的 sig-bio，目标是为 openEuler 拓展生物信息软件领域的生态。这可能是 openEuler 当前学术氛围最浓重的一个 SIG 了。maintainer 中有来自西安交大、哈工大以及中科院动物研究所的老师，也得到了麒麟和统信同学的积极响应。过去一个月中，sig-bio 的规模稳步增长，当前已经有 9 个生信领域的代码仓提交。这也是 openEuler 社区进入具体学科领域的第一次尝试，希望通过这样的工作，为建立一个高性能、可移植、可控可管理的生信软件栈做出些贡献。

3 月 29 日成立的 sig-rust，也可谓群英荟萃。张汉东、喻杰、王龙步、王璞等等都是国内 rust 圈子里有影响力的同学。随着 linux-next 开始接纳 rust 作为驱动构建途径，rust 在国内的影响力也有了进一步提升。openEuler 也在关注探讨如何在系统底层更好的使用 rust 这样的语言。sig-rust 的成立，在连接 openEuler 和 rust 两个社区的同时，也会为 rust 更好的在系统软件领域发挥作用探索道路。

此外，虽然 DB 并非新成立的 SIG，但是也在这段时间里有了非常大的变化。过去 openEuler 在数据库领域的策略并不清晰，DB sig 定位只是为了保证相关开源软件的基本可用。在 @赵波^[2] 等同学的努力下，DB sig 的 maintainer 和目标都做了巨大的调整。一方面将会引入更多的 OLTP 数据库到 openEuler，包括兄弟社区的 openGauss；另一方面也会围绕数据库引入生态工具，构建完整、丰富的数据库生产线软件生态。在此再次感谢 @郑振宇^[3]，@赵波^[4] 和 @陈祺德^[5] 老师的贡献。

从开发进展看 openEuler 社区当前进展

openEuler 社区整体的 PR，今天早上统计的时候已经是 31666 。去年 10 月底的时候还在 20000 左右，去年 12 月底开峰会的时候是 24700 左右。这意味着在 3 个月近 7000 个 PR。openEuler 依然保持着高速发展的势头，甚至可能比之前还更快了一点点。

不过我们还是看到其中的问题。以 src-openeuler 的情况看，大约有 20% 的未处理 PR 是最近两个月内创建的。考虑到 src-openeuler 项目已经运作了 15 个月，最近这段时间的 PR 积压的增速有些明显。我尝试对这些积压的 PR 做了一些简单的分类。

社区运营团队整理的 PR 清单中，已经 open 超过 30 天的 PR 有 168 个，其中 84 个是提交到 master 分支，27 个是提交到版本分支。值得注意的是还是有不少在 src-openeuler 自建分支的 PR。

从 PR 提交者的背景看，有超过一半来自独立贡献者。这从一定程度上反应，社区对独立贡献者的响应不及时，不是很友好。

从这些 PR 对应的 SIG 看，我们按降序排列了这类 PR 比较多的 SIG 组。

我对这些 PR 的内容作了些分析，可以看到存在以下几种问题。

Maintainer 没有及时响应是广泛存在的问题

上述排名靠前的 SIG 几乎都存在这个问题。聊举几例：

• https://gitee.com/src-openeuler/hdf/pulls/1
  
• https://gitee.com/src-openeuler/g2clib/pulls/1
  
• https://gitee.com/src-openeuler/nfs-fontmanager/pulls/1
  

这些例子中，提交者有些还通过 @ 的方式提醒了 SIG 的 maintainer，而对应的 maintainer 则可能因为各种原因没有注意到。openEuler 需要考虑在当前 gitee 机制之外，增加合适的通知提醒功能。

openEuler 的构建显然是有门槛的，而且这个门槛对一般开发者不友好

我注意到有几个面向特定场景的 SIG，基本上每个管理的代码仓都提交了相应的源码和 SPEC 文件，但是一个都没有通过 CI。

https://gitee.com/src-openeuler/openresty-zlib/pulls/1

[  149s] + make -j12 'CFLAGS=-O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -g3' 'SFLAGS=-O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -g3'
[  149s] /var/tmp/rpm-tmp.YqisDM: line 34: /dev/stderr: Permission denied

对应于的 spec 内容

make %{?_smp_mflags} CFLAGS='-O3 -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -g3' /
    SFLAGS='-O3 -fPIC -D_LARGEFILE64_SOURCE=1 -DHAVE_HIDDEN -g3' /
    > /dev/stderr

又比如：https://gitee.com/src-openeuler/openresty-pcre/pulls/1/

c82caabc test on unlimited virtual memory
244075b8 cat systemconfig
7be29532 cat config.log
a9a61008 bash -x
24220a21 openresty-pcre package init

从这个提交记录看，是一直找不到构建失败的原因，试图在 CI 里添加调试信息。然后最终还是没有成功：

[  149s] + ulimit -v unlimited
[  149s] /var/tmp/rpm-tmp.b7Psxi: line 50: ulimit: virtual memory: cannot modify limit: Operation not permitted

这是因为 openEuler 的构建环境是以普通用户 (abuild) 来运行的，普通用户的权限比 root 确实要受限的多。而一般开发者可能更习惯直接用 root 平 A 所有问题。另外，在 openEuler 的构建环境中，chroot 以后并不存在可以直接访问的 /dev/stderr 设备文件(或者符号链接)，这也是 openEuler 自身在构建上需要改进的点。

峰光的 compass-ci 项目花了很多心思在调测能力上，会尽快接入到 src-openeuler 的 CI 测试中。也希望各位 PR 的提交者，或者 maintainer ，遇到 CI 问题的时候，不要犹豫，在邮件和微信上联系我们。

CLA 检查失败依然是常见的问题

比如 https://gitee.com/src-openeuler/libxml2/pulls/34 中，小明后来反馈搞不清楚怎么处理，后来社区主线也收入了这个补丁，就不再关注在 openEuler 上跟进。根据后续的访谈，小明反馈了三个问题：

1. 感觉 openeuler 比 linux glibc 等其他社区提交更麻烦
   
2. 如果提交代码需要 先签署 CLA , 是否在注册 或 MR 创建时 勾选 更加方便一些。类似 注册软件时 勾选隐私协议
   
3. 然后按提示跳到 签署 个人 CLA 时, 网页报错。
   

另一类则是社区规则变更引起的，比如 https://gitee.com/openeuler/aarch32-rootfs-builder/pulls/33 停留了将近一个月，原因是 PR 提交者的 CLA 检查失败。这里有个背景需要说明。

大约在一个月前，参考其他社区的实现，经过酝酿，openEuler 社区 CLA 检查做了如下调整：

1. 从检查 PR 提交者改为检查该 PR 所包含的 commit 的作者，因为 CLA 作为代码贡献者协议，使用 commit 作者更准确；
   
2. 如果 PR 包含多位 commit 作者，需要都检查通过；
   
3. 因为 commit 作者是本地 git 配置的，可能和 gitee 上使用的注册邮箱不一致，如果 git 本地配置的邮箱未签署 CLA，则会导致 CLA 检查不过；
   
4. 建议保持本地 git 配置的邮箱和 gitee 上的邮箱一致，如确实需要不一致，烦请使用 git 本地配置邮箱再签署下 CLA；
   

这个变更知会的范围和渠道都存在需要改进的地方。

基础设施团队需要考虑做出针对性的改进。

小结

过去这两个月，openEuler 作为社区的发展之快，有的地方甚至超出预期。比如 kernel SIG 的线上会议，已经触及 zoom 当前允许的在线人数上限，逼得大家另外找开会的方法。

看到这些进展，开心之余，技术委员会还是会持续关注社区运作中存在的问题。毕竟我们做的，不是换换 logo 这样简单的事情。“为之于未有，治之于未乱” ，可以让我们对未来的发展更有信心。

参考资料