【sig-easylife第一次会议】
时间： 2020.11.12 19:00 ~ 20:00
与会人：
内容及结论：
1. SIG例会开展方式 - initlove
本次是首次开会，需明确后续的例会开展方式。
结论： a) 频率及时间：双周一次，具体时间在对应周的周一投票表决
b) 内容：各个子项目惯例过进展+介绍计划； 议题汇报，议题会前收集
c) 会议组织者：本次会上暂未讨论轮流计划，目前简化、暂由 initlove组织
2.
openEuler-Advisor/patch-trakcing/sync-bot 进展及计划 - xinweihu/各负责人
没记录，见各项目README/PR/ISSUE
3.
对外宣传 easylife项目 -
fangyufa/initlove
Easylife的对外推广有利于推动社区规范化、识别维护者痛点、推动高效可落地作业工具，希望吸引广泛的参与者。
openEuler Summit及其他 meetup上可以/有必要介绍easylife项目。
结论： a) openEuler Summit 2020.12.24 会上议题准备，建议相关owner准备材料（slide/demo）及议题，出差参加 。
4.
补丁命名规范问题 - licihua
无法识别补丁是来自上游社区还是来自openEuler社区，也无法识别社区修复的补丁是否回馈到上游社区。
结论： a) 这个是双向可追溯的问题。命名规则可以先出个初稿、在社区讨论；后续重点关注如何推动执行
5.
patchinfo问题 - initlove
在参与到漏洞补丁升级的时候，发现yum原生的updateinfo功能当前在openEuler没有很好支撑，OBS的patchinfo功能没有执行起来，这块目前正在研究方案。
结论： a) 这个和补丁命名规范在某种程度上说有共同的地方，都是数据结构化、以及如何推动的问题，可以互相交流。
6.
easylife各项目的许可证选型问题 - chenyanpan
当前easylife各项目许可证未确定。
结论： a) 没有许可证就不是开源软件，需要尽快拉上法务一起讨论、给出意见。
b) 各项目用统一一个许可证还是用不同许可证等到和法务讨论后明确。
7.
easylife下的项目是否可以不放到 src-openeuler下面 -
chenyanpan
放到src-openeuler下面多了一个打tar包、N个打补丁的工作，目前OBS支持直接拉git
repo代码的功能，能否优化成直接从 openeuler/XXX下面获取进行构建（但同样有spec、并且打成rpm包）。
结论： a) 这个在社区作为创新专题探索。从现代的开发/构建角度看，git开发 + 直连 git 进行构建似乎更高效。考虑到OBS也支持这个功能，因此可以原型试验。
b) 需要从LTS branch等各方面考虑，给一个详细方案。
c) 可以参考kernel团队当前做法
8.
各子项目 logo问题 - all stars
当前大家呼声选猫的图像作为各自logo，需要推动这个事情开展。
结论： a) 必须是猫，且猫必须是项目贡献者自己养的
b) 每个项目都投票选择一个logo（是否可以选相同的会上未讨论）
c) 每个项目被选中的猫的主人选相应的社区纪念品 (openEuler限量版猫砂及猫粮)
【遗留问题】
1. pkgship介绍 - wangyiru (下次例会上 11.26)
2. 准备openEuler Summit分享的材料 （slide/demo） - 各项目owner ( summit前 < 12.20)
3. 补丁的命名规范 - licihua (时间会上未讨论）
4. patchinfo - liangchenye （时间会上未讨论）
5. 各个项目的license选型问题 -- chenyanpan/liangchenye + 法务 ( 下次例会前 <11.26)
6. 是否可以省掉 src-repo - chenyanpan/liangchenye + kernel team （中期任务）
7. 猫logo投票 - fangyufa （ 紧急任务 < 11.20 )