三十辐共一毂，当其无，有车之用。埏埴以为器，当其无，有器之用。凿户牖以为室，当其无，有室之用。故有之以为利，无之以为用。
-- 《老子》第十一章
在众多同学的共同努力下，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 组。
| SIG 组名 |
30 天未处理 (合入/关闭) PR 数量 |
| UKUI |
16 |
| BaseService |
14 |
| Desktop |
13 |
| sig-ai-big-data |
12 |
| Mate-desktop |
10 |
| Application |
9 |
| Java |
8 |
| OpenResty |
6 |
| ROS |
6 |
我对这些 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 上跟进。根据后续的访谈，小明反馈了三个问题：
-
感觉 openeuler 比 linux glibc 等其他社区提交更麻烦
-
如果提交代码需要 先签署 CLA , 是否在注册 或 MR 创建时 勾选 更加方便一些。类似 注册软件时 勾选隐私协议
-
然后按提示跳到 签署 个人 CLA 时, 网页报错。
另一类则是社区规则变更引起的，比如 https://gitee.com/openeuler/aarch32-rootfs-builder/pulls/33 停留了将近一个月，原因是 PR 提交者的 CLA 检查失败。这里有个背景需要说明。
大约在一个月前，参考其他社区的实现，经过酝酿，openEuler 社区 CLA 检查做了如下调整：
-
从检查 PR 提交者改为检查该 PR 所包含的 commit 的作者，因为 CLA 作为代码贡献者协议，使用 commit 作者更准确；
-
如果 PR 包含多位 commit 作者，需要都检查通过；
-
因为 commit 作者是本地 git 配置的，可能和 gitee 上使用的注册邮箱不一致，如果 git 本地配置的邮箱未签署 CLA，则会导致 CLA 检查不过；
-
建议保持本地 git 配置的邮箱和 gitee 上的邮箱一致，如确实需要不一致，烦请使用 git 本地配置邮箱再签署下 CLA；
这个变更知会的范围和渠道都存在需要改进的地方。
基础设施团队需要考虑做出针对性的改进。
小结
过去这两个月，openEuler 作为社区的发展之快，有的地方甚至超出预期。比如 kernel SIG 的线上会议，已经触及 zoom 当前允许的在线人数上限，逼得大家另外找开会的方法。
看到这些进展，开心之余，技术委员会还是会持续关注社区运作中存在的问题。毕竟我们做的，不是换换 logo 这样简单的事情。“为之于未有，治之于未乱” ，可以让我们对未来的发展更有信心。
参考资料
[1]@huangtianhua: https://gitee.com/huangtianhua
[2]@赵波: https://gitee.com/bzhaoop
[3]@郑振宇: https://gitee.com/ZhengZhenyu
[4]@赵波: https://gitee.com/bzhaoop
[5]@陈祺德: https://gitee.com/dillon_chen
