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 幾乎都存在這個問題。聊舉幾例：

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

這些例子中，提交者有些還通過 @ 的方式提醒了 SIG 的 maintainer，而對應的 maintainer 則可能因為各種原因沒有注意到。openEuler 需要考慮在當前 gitee 機制之外，增加合適的通知提醒功能。

openEuler 的構建顯然是有門檻的，而且這個門檻對一般開發者不友好

我注意到有幾個面向特定場景的 SIG，基本上每個管理的程式碼倉都提交了相應的原始碼和 SPEC 檔案，但是一個都沒有通過 CI。

http://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

又比如：http://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 檢查失敗依然是常見的問題

比如 http://gitee.com/src-openeuler/libxml2/pulls/34 中，小明後來反饋搞不清楚怎麼處理，後來社群主線也收入了這個補丁，就不再關注在 openEuler 上跟進。根據後續的訪談，小明反饋了三個問題：

1. 感覺 openeuler 比 linux glibc 等其他社群提交更麻煩
2. 如果提交程式碼需要 先簽署 CLA , 是否在註冊 或 MR 建立時 勾選 更加方便一些。類似 註冊軟體時 勾選隱私協議
3. 然後按提示跳到 簽署 個人 CLA 時, 網頁報錯。

另一類則是社群規則變更引起的，比如 http://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 這樣簡單的事情。“為之於未有，治之於未亂” ，可以讓我們對未來的發展更有信心。

參考資料