openEuler 20200415 TC纪要//Re: 【Meeting Notice】openEuler TC meeting Time: 2020-04-15 10:00-12:00
openEuler 20200415 TC纪要
议题一、ROS sig 申请
1、同意申请，但openEuler本身闭源的软件治理还没有梳理清楚，建议先不包括闭源内容。
议题二、SDS sig 申请
1、成立分布式存储sig是有必要的，但是当前maintainer未明确，待分布式存储 maintainer 待定后，再进行申请。 2、当前适配的ceph-depoly/ceph-ansible 等工具完成适配后，直接提交PR申请，暂时纳入storage-sig 组进行管理。
议题三、Compatible-sig 申请
1、同意在社区成立兼容性sig 组申请。 2、同意在sig组下增加 服务器兼容性(OE cert)、并提供相关介绍材料及文档。 3、兼容性清单需要单独在社区呈现。
议题四、
1. 软件包在source-openEuler 发布按照现有sig维度发布，网络类软件包归属network sig，系统运维类软件包归属dev-utils sig 2. openEuler上创建一个eBPF-xdp 项目（名称暂定），用于一些创新项目、不成熟软件包的开发、维护工作。 遗留问题：原PR需要刷新-luzhihao
议题五：现有 SIG 运作review
1、 需要明确基于一致性检查识别200多软件包的重新归属问题，以及others里面的包重新梳理
2、 不同sig组的重新定位，比如DB和storage
3、 后续例会要例行review 各sig的运作情况
遗留问题：梳理清单以及分工-huxinwei
议题六：rpm package命名讨论
1、 先保持命名现状，避免影响升级等问题。后续软件包版本命名一致性规则由xiongwei制定，评审后发布。
议题七：Remove PRM包规则
1、建议在LTS版本周期内不能直接删除包，下一个版本要删除的话也要在repo保留。
遗留问题：梳理增包，删包流程并发布-huxinwei
---Original--- From: "Meeting Book via Tc"<tc@openeuler.org> Date: Wed, Apr 15, 2020 09:21 AM To: "tc"<tc@openeuler.org>; Subject: [Tc] 【Meeting Notice】openEuler TC meeting Time: 2020-04-15 10:00-12:00
Topic openEuler TC meeting Time 2020-04-15 10:00-12:00((UTC+08:00)Beijing) Join Conference Join (External) >> Meeting ID 929 074 130 76 Convener 王勋 Agenda 1. Review on existing SIG work(TC Members) 2. Review the suffix of rpm package (xiongwei) 3.SDS sig （dukaitian） 4.Discuss the package remove policy(TC Members) 5.compatible sig（dukaitian）
Tips: Dial the access number to join conference 注：仅支持部分国家和地区。( Only some countries and regions are supported.) 请点击会议链接按照提示下载Zoom客户端入会，并升级Zoom最新版本。 Please click the conference link and download the Zoom to join the conference, and upgrade to the latest version of Zoom.
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者 建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的 2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论
Regards 陈棋德
dillon.chen@turbolinux.com.cn
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。 openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。 这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 发送时间: 2020年4月16日 17:19 收件人: tc tc@openeuler.org 主题: [Tc] [Tc]建议拆分编程语言项目
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者 建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的 2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论
Regards 陈棋德 ________________________________ dillon.chen@turbolinux.com.cnmailto:dillon.chen@turbolinux.com.cn
我也赞同 dillon 的建议，针对 Python（Pypi）、Node.js（npm）、Perl（Cpan）、Ruby（rubygems）、Java（maven等）、PHP（Packageist） 、Rust（Cargo）这类的生态比较成熟、应用非常广泛的可以考虑建立独立的 SIG，建议 TC 或者 Programming-Language 组给一个指导性的原则。
要考虑后续逐渐有更多开源爱好者进来参与时，对于针对 Python、Node.js、Perl、Ruby、Java、PHP、Rust 比较专长的人员怎么快速的能够参与到相关 SIG 组的建立、相关包的扩充等。
另外，xinwei 提到了我理解目前 Linux 发行版的一个目前比较关键的问题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立包管理机制的关系。
现状是： 1. 这些语言类社区是发行版社区的一个上游社区 2. 每个语言类社区都会有的大量的包，甚至远大于 rpm 包的数量，但软件包的质量参差不齐 3. 发行版社区一般会选择部分包（一般包括运行环境、基础工具、底层包）使用系统包管理格式重新打包来引入 4. 发行版社区集成的包常常版本更新不及时，可能比语言类社区的版本号落后较多
定位分析： 1. 操作系统从定位讲，是整个软件生态的基础，每当发布一个版本后，很强调的一点是稳定，这样整个生态下的软件都能够在一个较稳定的平台上发展。 2. 而对于语言类社区来说，则更为开放，会比较激进的快速更新，快速扩张。比如 npm 已经 120 万了，上面说的这六个除了 Perl ，其他都在 10 万以上的规模，参考链接（http://www.modulecounts.com%EF%BC%89%E3%80%82%E3%80%82%E3%80%82 发行版的包数量一般应该还在 10 万以下吧。 3. 另外，不同语言类包的在系统的层级还不太一样， Python、Perl 包括其中基础的软件包已经被系统基础的工具依赖了，是系统必备的。Ruby、Node.js、Java 也有一些包处于这种角色。而 PHP、Rust 相比于系统感觉比较独立一些。
建议： 1. 较大型的语言类应该考虑建立单独的 SIG，尤其是系统依赖较多的，如 Python、Perl、Ruby、Node.js、Java 2. 系统除了包含这些语言的基础运行环境和基础工具外，SIG 组应该针对语言类社区中的软件包做分级，选择核心包、基础包等用 RPM 的方式打包引入 3. 语言类 SIG 组很重要的工作是后期维护，对于 Node.js 这类更新较快的是否跟随上游社区更新可能要慎重选择，首要原则应该是稳定与安全，维护原则应该与其他软件包类似，只不过维护的工作量可能要多一些。 4. 不建议针对用户级的做限制安装在 $HOME，用户应该可以选择安装在系统目录中还是用户目录下，毕竟对于多用户系统来说，在系统目录增加更多的软件来多用户共享使用是常见的需求。只要系统提供了基础环境，至于更多的包如何安装还是由用户自己选择。 5. 长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该采用统一的包管理优先。
供大家讨论参考。
——王建民
On 16 Apr 2020, at 5:27 PM, Huxinwei via Tc tc@openeuler.org wrote:
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。 openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。 这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 发送时间: 2020年4月16日 17:19 收件人: tc tc@openeuler.org 主题: [Tc] [Tc]建议拆分编程语言项目
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者 建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的 2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论Regards 陈棋德 dillon.chen@turbolinux.com.cn mailto:dillon.chen@turbolinux.com.cn_______________________________________________ Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
昨天的邮件回复错了，再贴一遍。
我同意xinwei的意见。因为python, perl这类的包数据量太庞大了，所以还是取决于上层软件包的引入，目前2000+的范围还凑合，但是如果再加更多的软件系统进来，这两个的数量就会急剧扩大，所以还是要尽快把上层的应用层的软件补齐，这样牵引我们来引入哪些python, perl等packge，对于其它没有显式rpm依赖的python, perl包，通过pip, cpan就可以了。倒未必非要都打成rpm包。
不过从长远来看，应该有专业的SIG组织来维护和演进这些语言类的package，确实非常专业。gcc, java这块已经有团队进行了看护，其它的语言类型不知道国内是否有比较强的团队能够搞起来。
在 2020-04-17 05:18:18，"Jianmin Wang via Tc" tc@openeuler.org 写道：
我也赞同 dillon 的建议，针对 Python（Pypi）、Node.js（npm）、Perl（Cpan）、Ruby（rubygems）、Java（maven等）、PHP（Packageist） 、Rust（Cargo）这类的生态比较成熟、应用非常广泛的可以考虑建立独立的 SIG，建议 TC 或者 Programming-Language 组给一个指导性的原则。
要考虑后续逐渐有更多开源爱好者进来参与时，对于针对 Python、Node.js、Perl、Ruby、Java、PHP、Rust 比较专长的人员怎么快速的能够参与到相关 SIG 组的建立、相关包的扩充等。
另外，xinwei 提到了我理解目前 Linux 发行版的一个目前比较关键的问题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立包管理机制的关系。
现状是： 1. 这些语言类社区是发行版社区的一个上游社区 2. 每个语言类社区都会有的大量的包，甚至远大于 rpm 包的数量，但软件包的质量参差不齐 3. 发行版社区一般会选择部分包（一般包括运行环境、基础工具、底层包）使用系统包管理格式重新打包来引入 4. 发行版社区集成的包常常版本更新不及时，可能比语言类社区的版本号落后较多
定位分析： 1. 操作系统从定位讲，是整个软件生态的基础，每当发布一个版本后，很强调的一点是稳定，这样整个生态下的软件都能够在一个较稳定的平台上发展。 2. 而对于语言类社区来说，则更为开放，会比较激进的快速更新，快速扩张。比如 npm 已经 120 万了，上面说的这六个除了 Perl ，其他都在 10 万以上的规模，参考链接（http://www.modulecounts.com%EF%BC%89%E3%80%82%E3%80%82%E3%80%82 发行版的包数量一般应该还在 10 万以下吧。 3. 另外，不同语言类包的在系统的层级还不太一样， Python、Perl 包括其中基础的软件包已经被系统基础的工具依赖了，是系统必备的。Ruby、Node.js、Java 也有一些包处于这种角色。而 PHP、Rust 相比于系统感觉比较独立一些。
建议： 1. 较大型的语言类应该考虑建立单独的 SIG，尤其是系统依赖较多的，如 Python、Perl、Ruby、Node.js、Java 2. 系统除了包含这些语言的基础运行环境和基础工具外，SIG 组应该针对语言类社区中的软件包做分级，选择核心包、基础包等用 RPM 的方式打包引入 3. 语言类 SIG 组很重要的工作是后期维护，对于 Node.js 这类更新较快的是否跟随上游社区更新可能要慎重选择，首要原则应该是稳定与安全，维护原则应该与其他软件包类似，只不过维护的工作量可能要多一些。 4. 不建议针对用户级的做限制安装在 $HOME，用户应该可以选择安装在系统目录中还是用户目录下，毕竟对于多用户系统来说，在系统目录增加更多的软件来多用户共享使用是常见的需求。只要系统提供了基础环境，至于更多的包如何安装还是由用户自己选择。 5. 长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该采用统一的包管理优先。
供大家讨论参考。
——王建民
On 16 Apr 2020, at 5:27 PM, Huxinwei via Tc tc@openeuler.org wrote:
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。 openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。 这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 发送时间: 2020年4月16日 17:19 收件人: tc tc@openeuler.org 主题: [Tc] [Tc]建议拆分编程语言项目
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者 建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的 2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论
Regards 陈棋德 dillon.chen@turbolinux.com.cn _______________________________________________ Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
从Debian，RedHat等Linux发行版的演进历史看也是逐渐演变到独立出这些语言的，社区是否包含这些包和openEuler发行版是否包含这些包是两回事，我的建议是提供这些包但不一定包括在发行版里面 myeuler也是认为长远角度是要建立SIG的。按xinwei的意见，我认为继续演进下去，相信长远也是要建立sig的，xinwei的意见稳妥但是演进会比较慢。一种是逐步演进，一种是现在就独立，长远的来说结果没什么区别。
jianmin意见和我一致，我提这个建议主要是从开发者角度提的，因为发现现有sig绝大多数都是从功能或适用场景来建立的。
折中一下，能否这样，如果jianmin提到的那6种大语言能够建立起专业的团队承接那么就建立SIG？
dillon.chen@turbolinux.com.cn
发件人： myeuler 发送时间： 2020-04-17 15:42 收件人： Jianmin Wang 抄送： Huxinwei; dillon.chen@turbolinux.com.cn; tc@openeuler.org 主题： Re:[Tc] Re: 答复: [Tc]建议拆分编程语言项目 昨天的邮件回复错了，再贴一遍。
我同意xinwei的意见。因为python, perl这类的包数据量太庞大了，所以还是取决于上层软件包的引入，目前2000+的范围还凑合，但是如果再加更多的软件系统进来，这两个的数量就会急剧扩大，所以还是要尽快把上层的应用层的软件补齐，这样牵引我们来引入哪些python, perl等packge，对于其它没有显式rpm依赖的python, perl包，通过pip, cpan就可以了。倒未必非要都打成rpm包。
不过从长远来看，应该有专业的SIG组织来维护和演进这些语言类的package，确实非常专业。gcc, java这块已经有团队进行了看护，其它的语言类型不知道国内是否有比较强的团队能够搞起来。
在 2020-04-17 05:18:18，"Jianmin Wang via Tc" tc@openeuler.org 写道： 我也赞同 dillon 的建议，针对 Python（Pypi）、Node.js（npm）、Perl（Cpan）、Ruby（rubygems）、Java（maven等）、PHP（Packageist） 、Rust（Cargo）这类的生态比较成熟、应用非常广泛的可以考虑建立独立的 SIG，建议 TC 或者 Programming-Language 组给一个指导性的原则。
要考虑后续逐渐有更多开源爱好者进来参与时，对于针对 Python、Node.js、Perl、Ruby、Java、PHP、Rust 比较专长的人员怎么快速的能够参与到相关 SIG 组的建立、相关包的扩充等。
另外，xinwei 提到了我理解目前 Linux 发行版的一个目前比较关键的问题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立包管理机制的关系。
现状是： 1. 这些语言类社区是发行版社区的一个上游社区 2. 每个语言类社区都会有的大量的包，甚至远大于 rpm 包的数量，但软件包的质量参差不齐 3. 发行版社区一般会选择部分包（一般包括运行环境、基础工具、底层包）使用系统包管理格式重新打包来引入 4. 发行版社区集成的包常常版本更新不及时，可能比语言类社区的版本号落后较多
定位分析： 1. 操作系统从定位讲，是整个软件生态的基础，每当发布一个版本后，很强调的一点是稳定，这样整个生态下的软件都能够在一个较稳定的平台上发展。 2. 而对于语言类社区来说，则更为开放，会比较激进的快速更新，快速扩张。比如 npm 已经 120 万了，上面说的这六个除了 Perl ，其他都在 10 万以上的规模，参考链接（http://www.modulecounts.com%EF%BC%89%E3%80%82%E3%80%82%E3%80%82 发行版的包数量一般应该还在 10 万以下吧。 3. 另外，不同语言类包的在系统的层级还不太一样， Python、Perl 包括其中基础的软件包已经被系统基础的工具依赖了，是系统必备的。Ruby、Node.js、Java 也有一些包处于这种角色。而 PHP、Rust 相比于系统感觉比较独立一些。
建议： 1. 较大型的语言类应该考虑建立单独的 SIG，尤其是系统依赖较多的，如 Python、Perl、Ruby、Node.js、Java 2. 系统除了包含这些语言的基础运行环境和基础工具外，SIG 组应该针对语言类社区中的软件包做分级，选择核心包、基础包等用 RPM 的方式打包引入 3. 语言类 SIG 组很重要的工作是后期维护，对于 Node.js 这类更新较快的是否跟随上游社区更新可能要慎重选择，首要原则应该是稳定与安全，维护原则应该与其他软件包类似，只不过维护的工作量可能要多一些。 4. 不建议针对用户级的做限制安装在 $HOME，用户应该可以选择安装在系统目录中还是用户目录下，毕竟对于多用户系统来说，在系统目录增加更多的软件来多用户共享使用是常见的需求。只要系统提供了基础环境，至于更多的包如何安装还是由用户自己选择。 5. 长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该采用统一的包管理优先。
供大家讨论参考。
――王建民
On 16 Apr 2020, at 5:27 PM, Huxinwei via Tc tc@openeuler.org wrote:
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。 openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。 这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 发送时间: 2020年4月16日 17:19 收件人: tc tc@openeuler.org 主题: [Tc] [Tc]建议拆分编程语言项目
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者 建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的 2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论
Regards 陈棋德
dillon.chen@turbolinux.com.cn _______________________________________________ Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
我整理了下现状，7大之外再加了个go，凑够8仙过海 ;)
Java: 当前80个Maven 软件包，包含maven自身。 Perl: 当前252个语言模块，已经集成了CPAN Python: 当前264个语言模块，已经集成pip (Pypi) Nodejs: 惭愧，openEuler中还是空白 -_-|| PHP: 更加惭愧，天下第一的语言，openEuler中也还是空白 -_-|| Rust: 只集成了rust本身，不过cargo是包含在其中的 Ruby: 当前7个语言模块，已经集成rubygem Golang: 当前19个语言模块，内嵌包管理
各位有没有推荐的大牛？我们可以尝试去接触下的。
Regards Xinwei
From: dillon.chen--- via Tc [mailto:tc@openeuler.org] Sent: Friday, April 17, 2020 4:15 PM To: myeuler myeuler@163.com; Jianmin Wang jianmin@iscas.ac.cn Cc: Huxinwei huxinwei@huawei.com; tc tc@openeuler.org Subject: [Tc] 回复: Re:Re: 答复: [Tc]建议拆分编程语言项目
从Debian，RedHat等Linux发行版的演进历史看也是逐渐演变到独立出这些语言的，社区是否包含这些包和openEuler发行版是否包含这些包是两回事，我的建议是提供这些包但不一定包括在发行版里面 myeuler也是认为长远角度是要建立SIG的。按xinwei的意见，我认为继续演进下去，相信长远也是要建立sig的，xinwei的意见稳妥但是演进会比较慢。一种是逐步演进，一种是现在就独立，长远的来说结果没什么区别。
jianmin意见和我一致，我提这个建议主要是从开发者角度提的，因为发现现有sig绝大多数都是从功能或适用场景来建立的。
折中一下，能否这样，如果jianmin提到的那6种大语言能够建立起专业的团队承接那么就建立SIG？
________________________________ dillon.chen@turbolinux.com.cnmailto:dillon.chen@turbolinux.com.cn
发件人： myeulermailto:myeuler@163.com 发送时间： 2020-04-17 15:42 收件人： Jianmin Wangmailto:jianmin@iscas.ac.cn 抄送： Huxinweimailto:huxinwei@huawei.com; dillon.chen@turbolinux.com.cnmailto:dillon.chen@turbolinux.com.cn; tc@openeuler.orgmailto:tc@openeuler.org 主题： Re:[Tc] Re: 答复: [Tc]建议拆分编程语言项目 昨天的邮件回复错了，再贴一遍。
我同意xinwei的意见。因为python, perl这类的包数据量太庞大了，所以还是取决于上层软件包的引入，目前2000+的范围还凑合，但是如果再加更多的软件系统进来，这两个的数量就会急剧扩大，所以还是要尽快把上层的应用层的软件补齐，这样牵引我们来引入哪些python, perl等packge，对于其它没有显式rpm依赖的python, perl包，通过pip, cpan就可以了。倒未必非要都打成rpm包。
不过从长远来看，应该有专业的SIG组织来维护和演进这些语言类的package，确实非常专业。gcc, java这块已经有团队进行了看护，其它的语言类型不知道国内是否有比较强的团队能够搞起来。
在 2020-04-17 05:18:18，"Jianmin Wang via Tc" <tc@openeuler.orgmailto:tc@openeuler.org> 写道： 我也赞同 dillon 的建议，针对 Python（Pypi）、Node.js（npm）、Perl（Cpan）、Ruby（rubygems）、Java（maven等）、PHP（Packageist） 、Rust（Cargo）这类的生态比较成熟、应用非常广泛的可以考虑建立独立的 SIG，建议 TC 或者 Programming-Language 组给一个指导性的原则。
要考虑后续逐渐有更多开源爱好者进来参与时，对于针对 Python、Node.js、Perl、Ruby、Java、PHP、Rust 比较专长的人员怎么快速的能够参与到相关 SIG 组的建立、相关包的扩充等。
另外，xinwei 提到了我理解目前 Linux 发行版的一个目前比较关键的问题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立包管理机制的关系。
现状是： 1. 这些语言类社区是发行版社区的一个上游社区 2. 每个语言类社区都会有的大量的包，甚至远大于 rpm 包的数量，但软件包的质量参差不齐 3. 发行版社区一般会选择部分包（一般包括运行环境、基础工具、底层包）使用系统包管理格式重新打包来引入 4. 发行版社区集成的包常常版本更新不及时，可能比语言类社区的版本号落后较多
定位分析： 1. 操作系统从定位讲，是整个软件生态的基础，每当发布一个版本后，很强调的一点是稳定，这样整个生态下的软件都能够在一个较稳定的平台上发展。 2. 而对于语言类社区来说，则更为开放，会比较激进的快速更新，快速扩张。比如 npm 已经 120 万了，上面说的这六个除了 Perl ，其他都在 10 万以上的规模，参考链接（http://www.modulecounts.com%EF%BC%89%E3%80%82%E3%80%82%E3%80%82 发行版的包数量一般应该还在 10 万以下吧。 3. 另外，不同语言类包的在系统的层级还不太一样， Python、Perl 包括其中基础的软件包已经被系统基础的工具依赖了，是系统必备的。Ruby、Node.js、Java 也有一些包处于这种角色。而 PHP、Rust 相比于系统感觉比较独立一些。
建议： 1. 较大型的语言类应该考虑建立单独的 SIG，尤其是系统依赖较多的，如 Python、Perl、Ruby、Node.js、Java 2. 系统除了包含这些语言的基础运行环境和基础工具外，SIG 组应该针对语言类社区中的软件包做分级，选择核心包、基础包等用 RPM 的方式打包引入 3. 语言类 SIG 组很重要的工作是后期维护，对于 Node.js 这类更新较快的是否跟随上游社区更新可能要慎重选择，首要原则应该是稳定与安全，维护原则应该与其他软件包类似，只不过维护的工作量可能要多一些。 4. 不建议针对用户级的做限制安装在 $HOME，用户应该可以选择安装在系统目录中还是用户目录下，毕竟对于多用户系统来说，在系统目录增加更多的软件来多用户共享使用是常见的需求。只要系统提供了基础环境，至于更多的包如何安装还是由用户自己选择。 5. 长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该采用统一的包管理优先。
供大家讨论参考。
——王建民
On 16 Apr 2020, at 5:27 PM, Huxinwei via Tc <tc@openeuler.orgmailto:tc@openeuler.org> wrote:
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。 openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。 这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 发送时间: 2020年4月16日 17:19 收件人: tc <tc@openeuler.orgmailto:tc@openeuler.org> 主题: [Tc] [Tc]建议拆分编程语言项目
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者 建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的 2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论
Regards 陈棋德 ________________________________ dillon.chen@turbolinux.com.cnmailto:dillon.chen@turbolinux.com.cn _______________________________________________ Tc mailing list -- tc@openeuler.orgmailto:tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.orgmailto:tc-leave@openeuler.org
Node.js 这块我推荐一个 Github 开源仓库 （Star * 2000）的作者，doramart， https://github.com/doramart/DoraCMS 。
他最近刚知道 openEuler 社区，还在看怎么加入。我觉得可以参与到 Node.js 这块 SIG 组的建立。我也抄送上他看是否能够参与进来。
我们基于 openEuler 的版本中针对 node.js 参考上游社区增加了 326 个包 nodejs- 开头的包，这块可以作为 openEuler 扩展 node.js 基础包的参考实现。
Jianmin
On 17 Apr 2020, at 5:03 PM, Huxinwei via Tc tc@openeuler.org wrote:
我整理了下现状，7大之外再加了个go，凑够8仙过海 ;)
Java: 当前80个Maven 软件包，包含maven自身。 Perl: 当前252个语言模块，已经集成了CPAN Python: 当前264个语言模块，已经集成pip (Pypi) Nodejs: 惭愧，openEuler中还是空白 -_-|| PHP: 更加惭愧，天下第一的语言，openEuler中也还是空白 -_-|| Rust: 只集成了rust本身，不过cargo是包含在其中的 Ruby: 当前7个语言模块，已经集成rubygem Golang: 当前19个语言模块，内嵌包管理
各位有没有推荐的大牛？我们可以尝试去接触下的。
Regards Xinwei
From: dillon.chen--- via Tc [mailto:tc@openeuler.org] Sent: Friday, April 17, 2020 4:15 PM To: myeuler myeuler@163.com; Jianmin Wang jianmin@iscas.ac.cn Cc: Huxinwei huxinwei@huawei.com; tc tc@openeuler.org Subject: [Tc] 回复: Re:Re: 答复: [Tc]建议拆分编程语言项目
从Debian，RedHat等Linux发行版的演进历史看也是逐渐演变到独立出这些语言的，社区是否包含这些包和openEuler发行版是否包含这些包是两回事，我的建议是提供这些包但不一定包括在发行版里面 myeuler也是认为长远角度是要建立SIG的。按xinwei的意见，我认为继续演进下去，相信长远也是要建立sig的，xinwei的意见稳妥但是演进会比较慢。一种是逐步演进，一种是现在就独立，长远的来说结果没什么区别。
jianmin意见和我一致，我提这个建议主要是从开发者角度提的，因为发现现有sig绝大多数都是从功能或适用场景来建立的。
折中一下，能否这样，如果jianmin提到的那6种大语言能够建立起专业的团队承接那么就建立SIG？
dillon.chen@turbolinux.com.cn
发件人： myeuler 发送时间： 2020-04-17 15:42 收件人： Jianmin Wang 抄送： Huxinwei; dillon.chen@turbolinux.com.cn; tc@openeuler.org 主题： Re:[Tc] Re: 答复: [Tc]建议拆分编程语言项目 昨天的邮件回复错了，再贴一遍。
我同意xinwei的意见。因为python, perl这类的包数据量太庞大了，所以还是取决于上层软件包的引入，目前2000+的范围还凑合，但是如果再加更多的软件系统进来，这两个的数量就会急剧扩大，所以还是要尽快把上层的应用层的软件补齐，这样牵引我们来引入哪些python, perl等packge，对于其它没有显式rpm依赖的python, perl包，通过pip, cpan就可以了。倒未必非要都打成rpm包。
不过从长远来看，应该有专业的SIG组织来维护和演进这些语言类的package，确实非常专业。gcc, java这块已经有团队进行了看护，其它的语言类型不知道国内是否有比较强的团队能够搞起来。
在 2020-04-17 05:18:18，"Jianmin Wang via Tc" tc@openeuler.org 写道： 我也赞同 dillon 的建议，针对 Python（Pypi）、Node.js（npm）、Perl（Cpan）、Ruby（rubygems）、Java（maven等）、PHP（Packageist） 、Rust（Cargo）这类的生态比较成熟、应用非常广泛的可以考虑建立独立的 SIG，建议 TC 或者Programming-Language 组给一个指导性的原则。
要考虑后续逐渐有更多开源爱好者进来参与时，对于针对 Python、Node.js、Perl、Ruby、Java、PHP、Rust 比较专长的人员怎么快速的能够参与到相关 SIG 组的建立、相关包的扩充等。
另外，xinwei 提到了我理解目前 Linux 发行版的一个目前比较关键的问题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立包管理机制的关系。
现状是：
- 这些语言类社区是发行版社区的一个上游社区
- 每个语言类社区都会有的大量的包，甚至远大于 rpm 包的数量，但软件包的质量参差不齐
- 发行版社区一般会选择部分包（一般包括运行环境、基础工具、底层包）使用系统包管理格式重新打包来引入
- 发行版社区集成的包常常版本更新不及时，可能比语言类社区的版本号落后较多
定位分析：
- 操作系统从定位讲，是整个软件生态的基础，每当发布一个版本后，很强调的一点是稳定，这样整个生态下的软件都能够在一个较稳定的平台上发展。
- 而对于语言类社区来说，则更为开放，会比较激进的快速更新，快速扩张。比如 npm 已经 120 万了，上面说的这六个除了 Perl ，其他都在 10 万以上的规模，参考链接（http://www.modulecounts.com%EF%BC%89%E3%80%82%E3%80%82%E3%80%82 发行版的包数量一般应该还在 10 万以下吧。
- 另外，不同语言类包的在系统的层级还不太一样， Python、Perl 包括其中基础的软件包已经被系统基础的工具依赖了，是系统必备的。Ruby、Node.js、Java 也有一些包处于这种角色。而 PHP、Rust 相比于系统感觉比较独立一些。
建议：
- 较大型的语言类应该考虑建立单独的 SIG，尤其是系统依赖较多的，如 Python、Perl、Ruby、Node.js、Java
- 系统除了包含这些语言的基础运行环境和基础工具外，SIG 组应该针对语言类社区中的软件包做分级，选择核心包、基础包等用RPM 的方式打包引入
- 语言类 SIG 组很重要的工作是后期维护，对于 Node.js 这类更新较快的是否跟随上游社区更新可能要慎重选择，首要原则应该是稳定与安全，维护原则应该与其他软件包类似，只不过维护的工作量可能要多一些。
- 不建议针对用户级的做限制安装在 $HOME，用户应该可以选择安装在系统目录中还是用户目录下，毕竟对于多用户系统来说，在系统目录增加更多的软件来多用户共享使用是常见的需求。只要系统提供了基础环境，至于更多的包如何安装还是由用户自己选择。
- 长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该采用统一的包管理优先。
供大家讨论参考。
——王建民
On 16 Apr 2020, at 5:27 PM, Huxinwei via Tc tc@openeuler.org wrote:
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python有pip，perl有cpan。 openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。 这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 发送时间: 2020年4月16日 17:19 收件人: tc tc@openeuler.org 主题: [Tc] [Tc]建议拆分编程语言项目
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也是生态的关键，尤其对软件开发者 建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的 2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论Regards 陈棋德 dillon.chen@turbolinux.com.cn _______________________________________________ Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
谢谢 建民兄 介绍
@doramart，您好，如果有兴趣了解下的话，我加您个微信？ ;)
Regards Xinwei
-----Original Message----- From: Jianmin Wang [mailto:jianmin@iscas.ac.cn] Sent: Friday, April 17, 2020 5:32 PM To: Huxinwei huxinwei@huawei.com Cc: tc tc@openeuler.org; dillon.chen@turbolinux.com.cn; myeuler myeuler@163.com; doramart@qq.com Subject: Re: [Tc] Re: 回复: Re:Re: 答复: [Tc]建议拆分编程语言项目
Node.js 这块我推荐一个 Github 开源仓库 （Star * 2000）的作者，doramart， https://github.com/doramart/DoraCMS 。
他最近刚知道 openEuler 社区，还在看怎么加入。我觉得可以参与到 Node.js 这块 SIG 组的建立。我也抄送上他看是否能够参与进来。
我们基于 openEuler 的版本中针对 node.js 参考上游社区增加了 326 个 包 nodejs- 开头的包，这块可以作为 openEuler 扩展 node.js 基础包的参 考实现。
Jianmin
On 17 Apr 2020, at 5:03 PM, Huxinwei via Tc tc@openeuler.org wrote:
我整理了下现状，7大之外再加了个go，凑够8仙过海 ;)
Java: 当前80个Maven 软件包，包含maven自身。 Perl: 当前252个语言模块，已经集成了CPAN Python: 当前264个语言模块，已经集成pip (Pypi) Nodejs: 惭愧，openEuler中还是空白 -_-|| PHP: 更加惭愧，天下第一的语言，openEuler中也还是空白 -_-|| Rust: 只集成了rust本身，不过cargo是包含在其中的 Ruby: 当前7个语言模块，已经集成rubygem Golang: 当前19个语言模块，内嵌包管理
各位有没有推荐的大牛？我们可以尝试去接触下的。
Regards Xinwei
From: dillon.chen--- via Tc [mailto:tc@openeuler.org] Sent: Friday, April 17, 2020 4:15 PM To: myeuler myeuler@163.com; Jianmin Wang jianmin@iscas.ac.cn Cc: Huxinwei huxinwei@huawei.com; tc tc@openeuler.org Subject: [Tc] 回复: Re:Re: 答复: [Tc]建议拆分编程语言项目
从Debian，RedHat等Linux发行版的演进历史看也是逐渐演变到独立出
这些语言的，社区是否包含这些包和openEuler发行版是否包含这些包是两 回事，我的建议是提供这些包但不一定包括在发行版里面
myeuler也是认为长远角度是要建立SIG的。按xinwei的意见，我认为继
续演进下去，相信长远也是要建立sig的，xinwei的意见稳妥但是演进会比 较慢。一种是逐步演进，一种是现在就独立，长远的来说结果没什么区别。
jianmin意见和我一致，我提这个建议主要是从开发者角度提的，因为发
现现有sig绝大多数都是从功能或适用场景来建立的。
折中一下，能否这样，如果jianmin提到的那6种大语言能够建立起专业
的团队承接那么就建立SIG？
dillon.chen@turbolinux.com.cn
发件人： myeuler 发送时间： 2020-04-17 15:42 收件人： Jianmin Wang 抄送： Huxinwei; dillon.chen@turbolinux.com.cn; tc@openeuler.org 主题： Re:[Tc] Re: 答复: [Tc]建议拆分编程语言项目 昨天的邮件回复错了，再贴一遍。
我同意xinwei的意见。因为python, perl这类的包数据量太庞大了，所以
还是取决于上层软件包的引入，目前2000+的范围还凑合，但是如果再加 更多的软件系统进来，这两个的数量就会急剧扩大，所以还是要尽快把上 层的应用层的软件补齐，这样牵引我们来引入哪些python, perl等packge， 对于其它没有显式rpm依赖的python, perl包，通过pip, cpan就可以了。倒 未必非要都打成rpm包。
不过从长远来看，应该有专业的SIG组织来维护和演进这些语言类的
package，确实非常专业。gcc, java这块已经有团队进行了看护，其它的语 言类型不知道国内是否有比较强的团队能够搞起来。
在 2020-04-17 05:18:18，"Jianmin Wang via Tc" tc@openeuler.org 写道： 我也赞同 dillon 的建议，针对 Python（Pypi）、Node.js（npm）、Perl（Cpan）、
Ruby（rubygems）、Java（maven等）、PHP（Packageist） 、Rust（Cargo） 这类的生态比较成熟、应用非常广泛的可以考虑建立独立的 SIG，建议 TC 或者Programming-Language 组给一个指导性的原则。
要考虑后续逐渐有更多开源爱好者进来参与时，对于针对 Python、
Node.js、Perl、Ruby、Java、PHP、Rust 比较专长的人员怎么快速的能够参 与到相关 SIG 组的建立、相关包的扩充等。
另外，xinwei 提到了我理解目前 Linux 发行版的一个目前比较关键的问
题是，尤其是目标作为根社区需要考虑的，系统包管理机制与各语言独立 包管理机制的关系。
现状是：
- 这些语言类社区是发行版社区的一个上游社区
- 每个语言类社区都会有的大量的包，甚至远大于 rpm 包的数量，但
软件包的质量参差不齐
- 发行版社区一般会选择部分包（一般包括运行环境、基础工具、底层
包）使用系统包管理格式重新打包来引入
- 发行版社区集成的包常常版本更新不及时，可能比语言类社区的版本
号落后较多
定位分析：
- 操作系统从定位讲，是整个软件生态的基础，每当发布一个版本后，
很强调的一点是稳定，这样整个生态下的软件都能够在一个较稳定的平台 上发展。
- 而对于语言类社区来说，则更为开放，会比较激进的快速更新，快速
扩张。比如 npm 已经 120 万了，上面说的这六个除了 Perl ，其他都在 10 万以上的规模，参考链接（http://www.modulecounts.com%EF%BC%89%E3%80%82%E3%80%82%E3%80%82 发行版的 包数量一般应该还在 10 万以下吧。
- 另外，不同语言类包的在系统的层级还不太一样， Python、Perl 包括
其中基础的软件包已经被系统基础的工具依赖了，是系统必备的。Ruby、 Node.js、Java 也有一些包处于这种角色。而 PHP、Rust 相比于系统感觉 比较独立一些。
建议：
- 较大型的语言类应该考虑建立单独的 SIG，尤其是系统依赖较多的，
如 Python、Perl、Ruby、Node.js、Java
- 系统除了包含这些语言的基础运行环境和基础工具外，SIG 组应该针
对语言类社区中的软件包做分级，选择核心包、基础包等用RPM 的方式 打包引入
- 语言类 SIG 组很重要的工作是后期维护，对于 Node.js 这类更新较快
的是否跟随上游社区更新可能要慎重选择，首要原则应该是稳定与安全， 维护原则应该与其他软件包类似，只不过维护的工作量可能要多一些。
- 不建议针对用户级的做限制安装在 $HOME，用户应该可以选择安装
在系统目录中还是用户目录下，毕竟对于多用户系统来说，在系统目录增 加更多的软件来多用户共享使用是常见的需求。只要系统提供了基础环境， 至于更多的包如何安装还是由用户自己选择。
- 长期来说，从操作系统作为一个软件产品角度，对用户来讲还是应该
采用统一的包管理优先。
供大家讨论参考。
——王建民
On 16 Apr 2020, at 5:27 PM, Huxinwei via Tc tc@openeuler.org wrote:
谢谢dillon的建议。
我们最近在梳理sig，语言类的软件以分布在Programming-language为主，
各个SIG中在处理各自依赖关系时也会直接引入。
我的想法是，当前成功的语言基本上都会有自己的管理体系，比如python
有pip，perl有cpan。
openEuler优先考虑把语言本身的包管理工具以rpm形式整合进来。 这样，原则上系统级（安装到/usr目录下的）由rpm方式管理；用户级
（安装到$HOME中）由语言自己的管理。
继续演进时，如果有其他rpm形式的软件对语言组件有依赖，则把这些
组件根据依赖关系引入。
也想听听各位TC委员和同好们的观点。
谢谢
发件人: dillon.chen--- via Tc [mailto:tc@openeuler.org] 发送时间: 2020年4月16日 17:19 收件人: tc tc@openeuler.org 主题: [Tc] [Tc]建议拆分编程语言项目
Hi all,
近期对比了一下openEuler和其他linux发行版，个人感觉目前openEuler和其他发行版差距最明显的地方在编程语言方面。而编程语言也 是生态的关键，尤其对软件开发者
建议： 1. 制定一个规则：什么条件下一门语言可以独立设置一个sig。然后根据这个规则设置一些独立的语言sig比如python，PHP，Perl之类的
2. 没能独立的编程语言继续放在编程语言sig中 3.语言类项目属于吃力不讨好的类型，如何承接才能做好我就不提了，请大家讨论
Regards 陈棋德 dillon.chen@turbolinux.com.cn _______________________________________________ Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
Tc mailing list -- tc@openeuler.org To unsubscribe send an email to tc-leave@openeuler.org
-
dillon.chen＠turbolinux.com.cn -
Huxinwei -
Jianmin Wang -
myeuler -
瓜-007