IT资讯 openEuler 社区 2021 年 3 月运作报告

donnie · 2021-04-15 15:30:06 · 热度: 4

三十辐共一毂,当其无,有车之用。埏埴以为器,当其无,有器之用。凿户牖以为室,当其无,有室之用。故有之以为利,无之以为用。

-- 《老子》第十一章

在众多同学的共同努力下,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 上跟进。根据后续的访谈,小明反馈了三个问题:

  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 这样简单的事情。“为之于未有,治之于未乱” ,可以让我们对未来的发展更有信心。

参考资料

[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

openEuler 社区 2021 年 3 月运作报告

文章转载自 OSCHINA 社区 [http://www.oschina.net]

猜你喜欢:
暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册