我们主要复用的开源软件用的是GPL、MIT。我们在新项目里的全新文件用木兰许可证没有大问题，不过会意味着少数场景不能复用一些开源代码。

先把最基础的功能跑通，理清头绪后，下个月切换到社区开发。这样安排如何？

 

发件人: Wubodong
发送时间: 2020年3月25日 9:36
收件人: wufengguang <wufengguang@huawei.com>; Xiehong (Cynthia) <xiehong@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>; Yang Li <runningforever@gmail.com>
抄送: Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; community@openeuler.org
主题: 答复: [Tc] 答复: [RFC] crystal-ci test as service

 

Openeuler开源许可证都是木兰吧

另外这个项目是可以run起来后，才开源社区运作吗

 

发件人: wufengguang
发送时间: 2020年3月25日 9:29
收件人: Xiehong (Cynthia) <xiehong@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>; Yang Li <runningforever@gmail.com>
抄送: Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Wubodong <wubodong@huawei.com>; community@openeuler.org
主题: 答复: [Tc] 答复: [RFC] crystal-ci test as service

 

可以咨询一下相关专业人士。另外采用什么开源许可证，也还有待决定。

 

发件人: Xiehong (Cynthia)
发送时间: 2020年3月24日 19:21
收件人: wufengguang <wufengguang@huawei.com>; Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>; Yang Li <runningforever@gmail.com>
抄送: Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Wubodong <wubodong@huawei.com>; community@openeuler.org
主题: 答复: [Tc] 答复: [RFC] crystal-ci test as service

 

这个项目要不要考虑先申请一个商标？ 如果是的话，注意不要有类似的名字

 

发件人: wufengguang via Tc [mailto:tc@openeuler.org]
发送时间: 2020年3月24日 18:56
收件人: Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>; Yang Li <runningforever@gmail.com>
抄送: Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; tc@openeuler.org; Wubodong <wubodong@huawei.com>; community@openeuler.org
主题: [Tc] 答复: [RFC] crystal-ci test as service

 

OK，大家的意见都是新建一个sig组。只是名字叫sig-cicd还是sig-crystal的差别。

两个名字看起来都挺好。如果没进一步的意见的话，我就任选一个啦。

 

发件人: Dukaitian (Dukaitian, Intelligent Computing R&D)
发送时间: 2020年3月17日 12:18
收件人: Yang Li <runningforever@gmail.com>; wufengguang <wufengguang@huawei.com>
抄送: Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; tc@openeuler.org; Wubodong <wubodong@huawei.com>; community@openeuler.org
主题: 答复: [Tc] [RFC] crystal-ci test as service

 

建议单独成立一个单独的sig-cicd，主要是为了构建、集成测试 项目划分的，后面这种类似，构建、集成测试的项目都可以放到这个sig组

 

 

另外crystal –ci  本身也可能会划分为多个项目来开展的。

 

 

 

 

 

 

杜开田 dukaitian

Email: dukaitian@huawei.com

Phone: 13631517269

Base: China-Shenzhen

欢迎加入鲲鹏论坛社区交流：https://bbs.huaweicloud.com/forum/forum-923-1.html

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

 

发件人: Yang Li [mailto:runningforever@gmail.com]
发送时间: 2020年3月17日 11:06
收件人: wufengguang <wufengguang@huawei.com>
抄送: Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; tc@openeuler.org; Dukaitian (Dukaitian, Intelligent Computing R&D) <dukaitian@huawei.com>; Wubodong <wubodong@huawei.com>; community@openeuler.org
主题: Re: [Tc] [RFC] crystal-ci test as service

 

我建议：

 

1、单独新建一个sig-crystal，可以在sig-QA的README里推荐crystal。这样更有利于大家关注到这个项目以及项目的内容。独立的项目更有利于孵化和开发。

2、项目成熟以后，可以申请移入到sig-QA的项目内。这样有利于把项目的成果向社区推广。

 

 

runningforever

签名由 网易邮箱大师 定制

On 3/11/2020 15:20，wufengguang via Tc<tc@openeuler.org> wrote：

各位TC，

我提议在openEuler下建一个子项目，基于openEuler对上游软件社区提供测试服务。
请问是新建一个sig好，还是复用将来要建立的QA sig?
PR打算在这里讨论之后发出。

项目名字
- crystal-ci
- crystal-dog
- 请大家多提议，开脑洞~~

项目目标
- 为社区提供测试服务，提升开源软件质量，促进openEuler生态繁荣

项目价值
- 测试上游软件git tree，解决开发者痛点
- BUG早发现
- 自动定位
- 一键复现
- 现场调试
- 测试服务环境基于openEuler，引导开发者使用，实现价值回馈循环

技术能力
- 全自动bisect-report-fix-verify闭环
- 性能分析比较
- 交互式DIY服务: 提交job, 分析结果, ssh登录调试

项目组成
- 一个开源框架及服务、工具套件，提供上述能力
- 利用现有开源资源，搭建具体项目测试
- linux kernel功能、性能测试
- 基于现有RPM spec、archlinux PKGBUILD实现对上游众项目的编译测试
- 部分openEuler OS测试 （与openQA互补）
- 各类基础软件的测试，可根据需求，探索展开

编程语言
- 复用和扩展社区已有的开源项目代码
- ruby/crystal
- python
- shell
- go
- 测试机上跑的
- 需求：易部署，低开销
- /bin/sh
- crystal
- 微服务
- 需求：高效 (machine, human)
- crystal
- 用户侧工具，数据分析与呈现，前端
- 需求：大众化，易上手DIY
- python
- d3.js, vue.js, ...
- 最佳搭配：我们提供数据/API，鼓励社区DIY工具与UI
- 一次性工具，性能不敏感
- 需求：方便
- ruby
- python
- shell (仅限小程序)

此致，
吴峰光

-----邮件原件-----
发件人: Guohanjun (Hanjun Guo)
发送时间: 2020年3月11日 12:45
收件人: tc <tc@openeuler.org>
抄送: Huxinwei <huxinwei@huawei.com>; wang.jing <wang.jing@i-soft.com.cn>; 张志高 <zhigao.zhang@i-soft.com.cn>; 冯倩倩 <qianqian.feng@i-soft.com.cn>; 宇亮 <liang.yu@i-soft.com.cn>; wufengguang <wufengguang@huawei.com>; Husheng (TommyLike) <hu.husheng@huawei.com>; Lizhonghua (OpenSource) <lizhonghua.li@huawei.com>; Liyongle (Fred) <liyongle@huawei.com>
主题: 会议纪要 //[Tc] 【Meeting Notice】Unscheduled openEuler TC meeting Time: 2020-03-11 10:00-12:00

1. Mate-desktop SIG建立 （遗留问题责任人 - 普华）
- 在PR中说清楚mate-desktop的作用，使用范围，以及涉及哪些软件包，方便review时从兼容性，作用等技术因素决定是否接受为新的SIG；
- 签署CLA；
- 需要新建立邮件列表；
- OBS系统构建对接，与胡胜（hu.husheng@huawei.com）联系；

2. 建立openEuler测试系统 （遗留问题责任人 - 吴峰光）
- 建立一个测试能力as service的系统，构建openEuler影响力，提议OK，建议创建新SIG，提PR进行review；

3. 会议时间变更，下周会议取消。下次会议3月25号（主持人张海亮），之后保持双周例会不变；

_______________________________________________
Tc mailing list -- tc@openeuler.org
To unsubscribe send an email to tc-leave@openeuler.org