feat: now also archive TC meeting minutes here

在此仓库归档 TC 的会议纪要，以便后续索引。

Log:

TC/Meeting Minutes/2022-00-Establishment.md

@@ -0,0 +1,54 @@
+Title: 社区技术委员会成立与章程公示
+Date: Fri, 21 Oct 2022 18:19:32 +0800
+---
+
+各位好，
+
+为了确保开源社区的稳健发展，不同开源社区通常都会存在一些组织来确保社区
+的有序发展，为社区内的各个组织提供支持与指导，指引社区的发展方向。尽管
+之前 deepin 之前也是近似的形式，但基本是以 deepin 官方身份为主开展，
+社区有兴趣和意向的贡献者并不能深入的参与到社区发展的讨论之中来。
+
+为了能使 deepin 技术方向方面的讨论可以变得更加公开透明，也使社区的朋
+友们可以更方便的参与到其中来，我们现成立了“社区技术委员会”，作为面向
+社区的领导性组织的存在。
+
+深度社区技术委员会（Technology Committee）是深度社区对技术领域决策
+相关的领导性组织，负责决策关于对特殊兴趣小组（SIG）的创建与监督、对新
+的打包维护者申请的审批、对打包流程的监督、对维护人员相关议题的处理和实
+施，以及其它与发行版建设相关的技术性问题。
+
+此委员会将会定期以公开例会的形式，对相关的问题进行商讨。在后续的发展中，
+此委员会的成员也会从现有的 SIG（特殊兴趣小组）中提名选出。我们希望以此
+确保我们的公开性，也确保有意向的朋友可以真正参与进来，一同助力 deepin
+社区的发展。
+
+社区委员会的章程目前[1]位于：
+
+https://www.deepin.org/index/docs/sig/TC/README
+
+目前，我们社区委员会的成员列表如下（均为 GitHub 用户名）：
+
+- mangosteens
+- kenshinwolf
+- matrix-wsk
+- shiptux
+- lwj786
+- movie0125
+- wangboa2020
+- Waleon
+- xuxiaodong
+- Zeno-sole
+- BLumia
+
+社区委员会后续的议题和例会都会以公开形式进行，例会在进行前也会在此邮件
+列表中进行公示。委员会相关事项有更新时，我们除了更新对应文档外，也会在
+此邮件列表进行同步公示。感兴趣的朋友可以留意此邮件列表来了解委员会的相
+关动态/参与进来。
+
+最后，再次感谢各位的关注！
+
+-----
+
+[1]: 此 url 对应的文章位置后续可能会变动，变动后，此 url 将包含指向
+     新的位置的链接

TC/Meeting Minutes/2022-10.md

@@ -0,0 +1,23 @@
+本次社区技术委员会例会已结束，以下是本次会议的纪要：
+
+首先我们对后续 TC 例会的展开位置、展开时间周期以及其他相关内容进行了讨论
+
+- 例会展开时间：每月最后一个工作周的周三，下午四点到五点进行。实际时间以此邮件列表中的公示为准
+- 例会展开位置：腾讯会议
+- 非例会时候的议题处理：在 deepin-community/community 下，由委员会成员发起议题进行讨论
+- TC 外部需要与 TC 进行直接沟通时：在 deepin-community/community 下创建 discussion，或在此邮件列表进行沟通
+- TC 日常实时交流协作平台：企业微信外部群（仅委员会成员使用）
+- 议题处理流程：根据社区反馈，由 TC 成员创建 issue，创建后，其他 TC 成员可直接在 issue 里进行讨论。稍微复杂的问题可以在 TC 群里讨论，如果还没有结果就放到例会。如果比较紧急，则可以增加临时会议。
+- 是否公开会议内容：只在邮件列表公开会议纪要，鉴于 TC 成立初期时，会议内容比较琐碎，故暂时不需要公开会议录屏。
+- 会议形式：暂时仅语音/视频的形式
+
+后续对 deepin v23 的软件包维护组织相关的问题进行了讨论
+
+- deepin-community 中承载了 deepin v23 的软件包维护所涉及到的相关仓库，公开的进行常规的软件包维护工作（现状）
+- 不同的软件包由不同的包维护性质的 SIG 进行维护，未有 SIG 对应的软件包，或 SIG 未能及时维护的软件包，则由包维护小组来进行维护
+- review 权限细分：每个包维护 SIG 分两个不同权限的人群，分别代表是否具有加分权限
+
+自由讨论阶段，由于初次例会，我们对委员会成员所提出的问题进行了相关说明
+
+- 委员会成员的职责：公开透明的讨论和处理 deepin 社区的与技术相关的议题
+- SIG 结构：包维护小组与非包维护小组，包维护性质的 SIG 负责维护一组性质相关的软件包，非包维护的 SIG 的日常活动则遵循其创建时所说明的目标来进行活动的展开

TC/Meeting Minutes/2022-11.md

@@ -0,0 +1,14 @@
+*注：本纪要存在内容订正，与原始发送到邮件列表的会议纪要有内容差异。原文与定制内容请参见 deepin-devel 邮件列表*
+
+本次社区技术委员会例会已结束，以下是本次会议的纪要：
+
+mangosteens 因其它会议时间冲突，暂时无法参加。此外有另外两个成员未参与会议，分别是：
+
+matrix-wsk
+kenshinwolf
+
+会议上，我们讨论了关于是否建设 deepin 社区自己的 Matrix 实例的问题。与会者均同意搭建深度开源社区自己的 matrix 实例，搭建后则要求后续各个 SIG 在 matrix 实例中创建对应的房间进行相关的讨论活动（而不是企业微信群）。对于某些方向的特定讨论（类似“OBS 服务”、“包选型”、“DTK”）也会建立对应的房间供讨论。以便达到公开讨论的目的。
+
+作为额外说明，deepin 目前已经存在公开的 Matrix 房间来进行包括常规的开发问题、移植问题之类的讨论。可以查阅 https://wiki.deepin.org/zh/%E5%85%B3%E4%BA%8EDeepin/Deepin%E7%A4%BE%E5%8C%BA/%E4%BA%A4%E6%B5%81%E6%96%B9%E5%BC%8F 了解和加入目前已有的实时聊天渠道。
+
+在自由讨论阶段，我们讨论了关于 SIG 进行公开进度汇报/成果展示所应当使用的平台。讨论后，我们决定，为了便于 SIG 的进度公示/成果展示，我们在 SIG 成立后直接帮 SIG 建立其对应的静态博客平台，然后由 SIG 自主维护自身博客的更新。另外，由 TC 维护一个总的汇总平台来订阅和汇总展示 各个 SIG 的进度公示/成果展示。简单而言，对于 SIG 组而言，实际工作即在特定的位置放 markdown 文档。SIG 也可以根据自身需要来维护对应的博客平台，来满足 SIG 的实际需求。

TC/Meeting Minutes/2022-12.md

@@ -0,0 +1,16 @@
+本次社区技术委员会例会已结束，以下是本次会议的纪要：
+
+本次会议有五人未参会，其中两人因病无法参会并提前告知了情况。考虑到现阶段新冠对各位带来的影响，本次不再公示未及会人员名单。
+
+本次会议主题为自由讨论，主要讨论的议题大多与仓库和包维护相关，内容大致如下：
+
+- 现有 gcc 版本存在 PIE 选项默认未启用的问题 [1]，应当由 gcc-packaging SIG 进行处理
+- 尽管社区的包维护主要会发生在 deepin-community 组织下，但由于部分软件包内的文件过大，无法在 GitHub 直接进行维护。对于此类软件包的维护，我们将会在 OBS 进行维护，相关的软件包列表可参见这里 [2]。若有类似原因希望新增无法在 deepin-community 组织进行维护的仓库，则可以联系 sysdev 组，单独申请创建 OBS 帐号，直接在 OBS 维护对应的软件包。
+- 关于项目研发过程涉及的 tag 创建事宜，我们使用了更新 debian/changelog 时自动创建 tag 的方案。对于 linuxdeepin 组织下的仓库，创建 tag 时会忽略 changelog 中的 epoch 与 rebuild 部分，而 deepin-community 会在创建的 tag 中保留 epoch 与 rebuild 部分（其中， : 会替换为 % ， ~ 会替换为 _ ）。
+- 关于 dpkg，提出了为其增加 zstd 支持的讨论。此需求仅为添加 zstd 支持而非默认打 zstd 压缩格式的包，不存在兼容问题，故可以实施。会转 deepin-pkg SIG 处理。
+- 此外，还提出了 dpkg 添加 no-udeb 来 ban 掉 udeb 打包支持，以及添加新增的 xz 多线程压缩支持 [3] 的事项，均可实施，会转 deepin-pkg SIG 处理。
+- 关于包的选型范围，由于可能涉及到基础项目外的一些额外软件包（component 对应到 community [4]），会由 sysdev SIG 维护，且此 component 下的软件包仅确保基本的构建和使用，在有包维护人员认领前，不会进行刻意的更新或维护。
+
+除这些议题外，本次也提议新的成员 @Rabenda 加入 TC 委员会成员之中。本次参会的总 6 位现有 TC 成员均同意，无人反对，满足超 1/3 赞同且无反对的准入要求。故欢迎其成为 deepin 社区委员会成员 :)
+
+最后，由于一月份的最后一个工作周的周三为节假日，我们商定调整了下次会议时间，即暂定 23 年 1 月的例会将于 23 年 2 月 1 日进行。

TC/Meeting Minutes/2023-01.md

@@ -0,0 +1,17 @@
+本次社区技术委员会例会已结束，本次会议共 12 人参与，另有两人因事未参与本次会议。以下是本次会议的纪要：
+
+deepin 软件仓库的包版本号规范目前虽有大致规范，但仍存在一些问题。基本共识为当前分支与 tag 规范中原定的版本号规范。讨论后，我们决定由 @Zeno 拟定一份具体的版本号规范，并随后发布至（此）邮件列表中以供进一步讨论。此外，若存在研发分支之类的情况，则研发分支中的版本发布应当先使用 unreleased，并在合入主线后再进行版本发布。
+
+除软件包的版本号外，软件包的准入和准出规范也有待明确，我们同样需要明细话相关的规范。以及与此相关的，我们需要一个可以用来追踪软件包的生命周期/维护状态等的追踪平台（类似 tracker.debian.org）。此需求应当后续在 sysdev 小组进行进一步的详细讨论来推进。
+
+另外，目前 deepin 社区对于各项规范的指定目前并没有类似 RFC/proposal 的明确机制（注：TC 成立时章程的拟定有一个初步的规范，但也不够细致），故提 RFC/proposal 的流程本身我们也应当着手进行明确化。在此之前，若有提出 proposal 的需求，则仍以此邮件列表为主进行讨论。
+
+其他问题上，此前 TC 例会提到的 dpkg 软件包的维护，原本由 deepin-pkg SIG 进行相关特性的维护支持，但现在相关特性已经进入 dpkg 上游仓库的主干，故我们不再需要额外进行刻意维护，仅需常规更新此软件包的版本即可。
+
+关于软件包的维护，Revy 提出目前 OBS 对于 debian 的打包构建仍然存在一些问题，其中必要重要的问题包括自举依赖的软件包需要人工进行干预才能恰当处理（典例为 rust），以及 OBS 默认对 debian 依赖的解析不一定正确，需要干预 build profile。我们决定对这些 OBS 的功能缺陷移至会后进行进一步的详细讨论，并事情况权衡后续的处理方式。
+
+Revy 还提出了目前 haskell 软件包维护过程遇到的问题，包括对软件包的修订很容易触发大范围的 rebuild（软件包维护涉及版本变化，版本变化会导致 hash 变化，此时就必然需要 rebuild）。在讨论后暂时也没有得到较好的处理方式，故如果你有相关想法，欢迎通过邮件列表或其他方式联系我们，一同参与讨论。
+
+最后，关于 v23 DDE 以及 deepin 应用的迁移与打包以及移植，为了便于内外都能有效的利用迁移的代码来构建 v23 DDE，我们讨论决定随后将即将发布的 v23 alpha 2 的 tag 列表以 issue 和邮件列表的形式进行公示，以供所有相关人员参考。另外，由于目前对 v23 分支的迁移方式导致 v23 分支的最新 tag 会落在合并 v23 代码时的最后一个提交上，故此 tag 列表与 v23 alpha 2 中实际进行 tag 构建的版本可能存在一定程度的出入，故相关人员在构建 tag 版本若遇到问题，则请以 issue 的形式或在 dde-porting 小组反馈给我们，我们将会尽快处理于此相关的问题。我们也会在后续尽可能避免此类“内部研发强制合并到主干”现象的存在。
+
+以上即为此次例会所讨论的所有议题。若有遗漏或若需补充，或是进行相关的正式讨论，可直接回复此邮件。

TC/Meeting Minutes/2023-02.md

@@ -0,0 +1,24 @@
+本次社区技术委员会例会已结束，本次会议共 9 人参与，另有两人因事未参与本次会议。以下是本次会议的纪要：
+
+本次会议邀请 dde-kwin 维护人员 @justforlxz 参与了相关讨论，提出了目前所选 fork KWin 策略所相关的若干问题。
+其中包括对上游代码的同步变得更加困难，以及实际目的所产生的差异接口较少，是否应当向 KWin 上游推进的问题。由此
+引申了相关接口的维护方式的讨论（是否可以以插件形式维护等）以及 KF5 相关软件包依赖情况与 KF 软件包在 deepin
+发行版的维护问题。
+
+对于差异接口问题，我们认为应当视情况考虑向 KWin 上游推进必要的接口。对于软件包维护问题，我们暂时决定保持“谁
+依赖，谁维护”的策略维护，由相关项目组与 SIG 梳理 KF 软件包的依赖情况，并酌情考虑建立 SIG 进行维护。
+
+后续，我们展开了与之相关的讨论，包括当前 deepin 发行版的 Wayland 支持现状以及相关计划。目前由 wm 相关的人员
+维护，后续 wm 相关也可能以 SIG 的形式进行活动的展开。
+
+另外，目前观察到，现有的部分 SIG（例如维护 dpkg 等打包相关的软件包 deepin-pkg SIG，维护 GCC 的  
+gcc-packaging SIG 等）没有在正常工作，我们讨论决定先与相关人员取得联系，然后再决定进行进一步的讨论。
+
+本次也提出了是否参与 GSoC 的问题，但根据实际情况，我们已经错过了本年 GSoC 组织提交申请的提交 deadline。
+（撰写纪要时补充：对于后续 GSoC 参与，则建议在年底即着手准备相关主题，然后准备递交，并建议适当调整代码之季的时间。
+也可以考虑参与其他相关活动，可在 TC 相关群组展开讨论）
+
+最后，本次由 @BLumia 提议邀请 @justforlxz 加入 TC。由于本次与会缺席人数较多，我们决定于会后在 TC 群中进行投票，
+请各位 TC 成员留意群组消息。
+
+以上即为此次例会所讨论的所有议题。若有遗漏或若需补充，或是进行相关的正式讨论，可直接回复此邮件。

TC/Meeting Minutes/2023-03.md

@@ -0,0 +1,59 @@
+本次社区技术委员会例会已结束，本次会议共 15 人参与，有 1 人因事未参与本次会议，其余所有 TC 成员均参会，另有 2 位非 TC 成员参与了旁听。
+
+根据会议前原定的议题，我们依次进行了相关讨论。以下是本次会议的纪要：
+
+1. 关于 @justforlxz 与 @felixonmars 成为 TC 成员的决议投票
+
+所有参会成员均同意，无反对票。两位成为深度社区 TC 的新成员。新的 TC
+成员名单会于随后进行更新与公示，目前 TC 成员总计 14 人。
+
+2. 考虑移除没有实质进行活动开展的、不再活跃的包维护 SIG (@BLumia)
+
+原有的包维护 SIG 大多未在实际进行包维护活动的展开，随后会联系各包维护
+SIG，确认是否确实不再参与，并将不再参与的 SIG 进行归档并在列表中移除。
+包的实质性维护工作目前由 sysdev 组进行，也会在归档相应 SIG 时进行声明，
+以便社区贡献者可以找到有效的信息并参与贡献。
+
+另外，由 @revy 指出，目前包维护的工作并未完全做到全流程可公开参与（即
+仍需 sysdev 主动干预/提供支持才能完成相应的工作），这相关的流程问题有待
+sysdev 组进一步完善。若有必要，仍允许（且建议）将相关的流程逐步拆分或
+划分新的 SIG 展开对应的工作。
+
+3. 发起 RFC 流程的规范拟定（希望征集有什么必须包含在内的内容） (@Revy, @BLumia)
+
+对于 RFC 的拟定大概流程，暂定了以 GitHub Pull Request 的形式进行 RFC 的
+发起与 Review，以合入作为 RFC 正式采纳的标志。@revy 补充了关于 RFC 应当
+先进行编号的授予的要求，此步骤用以标志相关提案确属 TC 应当关注的流程。
+编号授予后，需要经过 TC 决议来表示 RFC 的批准拟定。
+
+另外，@felixonmars 提出，RFC 的制定流程本身应当考虑 RFC 所需要涵盖的范围
+边界，避免 RFC 被用以作为意图外的争论缘由等问题。具体拟定过程中也会参考
+其他社区的 RFC 提议流程。
+
+4. 软件包的 Section/Area 组件标明，希望主动标明 (@Revy)
+
+@revy 诉求：rv 无法分辨如何进仓
+@zeno 考虑：目前仓库变化可能很大，建议在正式版发布后再进行相关规范的
+实施
+
+最终讨论后，@revy 目前决定放弃此诉求
+
+5. 保留原始包的相关信息，拉包的时候保留原始信息，例如 X-Original-SomeKey: (@Revy)
+
+讨论结果：方案本身没问题，具体方案需要调研后具体确认。另外，实施相关
+规范并不会要求更改已经集成进仓的软件包，只会对新增的软件包进行要求。
+
+后续的自由讨论过程中，展开了大致如下内容的讨论：
+
+1. 新架构移植：@revy 提出了龙芯架构支持，希望加到正式的支持架构里
+
+认同此提议，若完整支持此架构的话，涉及的相关工作可能会比较多，@revy
+表示会在 RFC 拟定流程明确后发起相关 RFC 进行相关的详细讨论。
+
+2. @matrix-wsk 讨论了关于内核相关维护活动的开展计划
+
+内核 SIG 的后续活动开展会在 deepin-community 组织下，实时沟通会在
+matrix 的内核 SIG 对应的聊天室进行。并与各位讨论了关于内核集成的
+相关问题。
+
+以上即为此次例会所讨论的所有议题。若有遗漏或若需补充，或是进行相关的正式讨论，可直接回复此邮件。

TC/Meeting Minutes/2023-04.md

@@ -0,0 +1,26 @@
+本次社区技术委员会例会已结束，本次会议共 14 人参与，另有一人因事请假未参与本次会议。以下是本次会议的纪要：
+
+1. 深度社区提案与进入备忘录的流程讨论与决议：
+
+经过决议，过半人数同意且无反对意见，故相关议题通过。后续的社区提案将在 deepin-community/rfcs 仓库下发起，并遵循所拟定的规范进行实施。若提案流程存在问题，则提案流程本身也可进行再次讨论与修订。
+
+2. deepin-community 组织 GitHub Action 问题讨论：
+
+讨论决定暂时使用第三方 CI 完成现有任务，对于现有的类如自动打 tag 的流程也尽量考虑使用 Webhooks 方案，避免在软件包仓库放置与软件包无关的配置文件。
+
+3. Han Gao：目前没有公开的 Release Team
+
+目前的版本发布确实并非完全透明，待与现有内部团队讨论。在能够使社区 Release Team 公开透明的控制版本发布之前，可考虑将版本发布相关的计划等信息进行有效披露。
+
+4. Han Gao：openEuler SIG 这类 SIG 是否有创建的必要性
+
+我们并不要求主要活动于其它平台的 SIG 在深度社区创建对应的 SIG，但也不反对创建这样的 SIG。当然，SIG 的创建要求相应的小组成果。若观察到小组并未产出有意义的小组成果，小组可能会在后续被归档。
+
+5. Felixonmars/Han Gao：可协作编辑的会议纪要
+
+Archlinux 以及 Debian 社区在开展线上会议甚至线下会议时，会采用类如 HackMD 或是 HedgeDoc 的平台进行协作编辑。包括入会时的签到，议题内容的记录、更新与补充均直接由参会人员直接自行编辑完成，会议结束后即可直接得到完整的会议纪要。
+
+后续待调研相关流程。若没有问题，后续可进行决议是否要根据此方案进行实施。
+
+
+以上即为此次例会所讨论的所有议题。若有遗漏或若需补充，或是进行相关的正式讨论，可直接回复此邮件。