获取 Gentoo！

GLEP 39：Gentoo 元结构

作者 Grant Goodyear <[email protected]>，Ciaran McCreesh <[email protected]>
类型 信息性
状态 最终
版本 3
创建日期 2005-09-01
最后修改日期 2023-05-08
发布历史 2005-09-01, 2006-02-09, 2007-10-12, 2008-01-19, 2022-11-25, 2023-04-10, 2023-04-16
替换 4
GLEP 源代码 glep-0039.rst

状态

已实施。元结构提案已于 2005 年 6 月 14 日获得所有 Gentoo 开发人员投票通过 [1]。GLEP 于 2006 年 2 月 9 日进行了修订，在 规范 中列表 B 中添加了最后一个要点。

2023 年 5 月 8 日由所有开发者投票更新

  • 由下一位候选人取代离任的理事会成员 [2]。
  • 更新此文档需要所有开发者投票 [3]。
  • 理事会成员必须是开发者 [4]。
  • 人数不足的理事会会议不得采取任何实质性行动。
  • 取消每年项目负责人选举的硬性要求。

摘要

GLEP 4 被一个新的“元结构”所取代，该结构保留了已建立的项目（并使新项目的创建更容易），但增加了一个新的“Gentoo 理事会”来处理全局（跨项目）问题。

动机

Fosdem 和随后由 Koon 主导的改革提案非常全面、极其详细且有些复杂。它们包含许多好想法。然而，对于许多长期参与 Gentoo 的人来说，他们对这些提案有些不满意。许多 Gentoo 开发人员几乎完全对元结构不感兴趣，只要它不阻碍他们的工作，并且由于当前的提案至少对我们难以驾驭的开发者施加了一些秩序，因此这些提案肯定会“妨碍”某种程度上的工作。例如，一个经常听到的评论是，许多 Gentoo 开发人员不知道他/她的经理（或项目负责人）是谁，这清楚地表明我们目前的系统已崩溃。现有提案通过要求每个开发人员都属于一个项目来解决这个问题。然而，也许已损坏的部分是，认为每个开发人员都应该有一个经理。Gentoo 的历史表明，传统上，重大进步通常是由一个或少量敬业的开发者实施的（因此我们长期以来的传统是开发人员可以访问整个树），并且我们当然不想让这些人的工作变得更难（或不那么有趣）。因此，这是一个针对那些记得“过去美好时光”并认为现在情况并没有真正改变的人的最小提案。

当前系统的概要

  • 有 13-15 个顶级项目（TLP）。顶级项目由子项目组成，目标是每个 Gentoo 项目都是其中一个 TLP 的子项目。据推测，因此每个开发者都属于一个或多个 TLP。
  • 每个 TLP 至少有一个“战略”经理，并且可能还有一个“运营”经理。只有战略经理才能对 Gentoo 的全局问题进行投票。
  • 每个 TLP 的经理由 drobbins、其他 TLP 经理任命，或由其项目成员选举产生。这些经理没有固定的任期。
  • 在每个 TLP 内，经理负责对项目做出决策，为项目定义明确的目标、路线图和时间表，并解决 TLP 中出现的问题（有关具体列表，请参阅 GLEP 4）。
  • 战略 TLP 经理还负责决定影响 Gentoo 跨项目的问题。处理全局范围问题的首要机制是经理会议。
  • 对犯错的开发者采取的纪律处分由“devrel”TLP 处理，除非该开发者是战略 TLP 经理。在这种情况下，纪律处分必须由其他战略 TLP 经理执行。

现有系统的问题

  1. TLP 完备性的假设要么不正确（仍然没有“服务器”TLP），要么纯粹奇怪（但缺少服务器 TLP 在技术上是可以的，因为所有没有明显 TLP 的开发者默认属于“基础”TLP）。
  2. 没有任何东西可以确保项目负责人实际上代表他们声称领导的开发者或履行其职责。事实上，如果 TLP 经理突然失踪，解决这种情况的方法并不明显。
  3. 目前在全局范围内没有任何决策。一些 TLP 战略经理很少参加经理会议，并且经理们作为一个整体肯定没有为 Gentoo 提供任何全局愿景。
  4. 即使战略 TLP 经理正在为 Gentoo 做出全局决策，TLP 结构也使得几乎所有开发人员都只属于一两个 TLP。因此，对全局问题的投票并不成比例，因此许多开发人员感到被剥夺了权利。
  5. 无论是否有道理，devrel 在其执行角色中都被许多人厌恶。

当前元结构改革提案中发现的其他问题

  1. 当前系统没有机制来识别已停止活动的项目或开发者。
  2. 跨项目的错误通常无法解决。
  3. GLEP 通常处于不确定的状态。

规范

  1. 项目是一组开发人员为实现目标（或一组目标）而努力。
    • 如果项目具有下面描述的维护的 Wiki 项目页面，则该项目存在。（“维护”表示页面上的信息在事实和时间上都是正确的。）如果 Wiki 页面未维护，则假定其已失效。
    • 它应该至少有一个负责人，负责人由项目成员选出。此选举应至少每 12 个月进行一次，并且可以在任何时间进行。如果上次选举超过 12 个月，任何成员都可以要求进行负责人选举。
    • 它可能具有零个或多个子项目。子项目只是提供一些额外结构的项目，其 Wiki 页面被定义为父项目的子项目。
    • 并非所有内容（或所有人）都需要项目。
    • 项目不需要长期存在。
    • 项目可能与其他项目冲突。这没关系。
    • 任何开发人员都可以通过在 wiki.gentoo.org 上创建一个新的项目页面（请参阅 [5]）并向 gentoo-dev 发送“征求意见”（RFC）电子邮件来创建新的项目。请注意，此 GLEP 没有提供让社区阻止新项目的方法，即使评论完全是负面的。
  2. 全局问题将由选举产生的 Gentoo 理事会决定。
    • 理事会成员将有固定数量。（对于第一次选举，该数字通过鼓掌表决确定为 7。）
    • 理事会成员将由所有开发人员每年进行一次普选选出。
    • 理事会成员（及其代理）必须是 Gentoo 开发人员。
    • 理事会必须至少每月举行一次公开会议。
    • 理事会决策由出席会议者（或其代理）的多数票决定。
    • 如果理事会成员（或其指定的代理）连续两次会议未出席，则将其标记为“懒惰”。
    • 如果被标记为“懒惰”的理事会成员错过任何后续会议（或其指定的代理未出席），则他们将失去职位。
    • 每当理事会成员失去职位时（原因无关紧要；例如，他们辞职或因懒惰被免职），则提供该职位给上一届理事会选举中排名下一位的候选人。如果他们接受并且现任理事会一致同意新成员，则他们获得该职位。否则，将该职位提供给排名下一位的候选人，依此类推。如果理事会不接受该候选人，则将举行新的选举以选出新成员。新成员获得“缩短”的任期，以便年度选举仍然选举出一个完整的团队。
    • 之前因过度懒惰而被免职的理事会成员可以参加未来的选举，包括其替代者的选举。但是，他们应该为自己的懒惰行为辩护，并且如果他们自己不这样做，他们应该预计会有人指出这一点。
    • 当成员当选时，“懒惰”标记将重置。
    • 如果任何会议的理事会成员出席率低于 50%，则必须在一个月内针对所有职位举行新的选举。“一年”从那时起重置。在任何此类会议中均不得采取任何实质性行动。
    • 纪律处分可以向理事会提出申诉。
    • 代理人不得是现任理事会成员，并且任何单个人在任何给定会议上都不能是多于一名理事会成员的代理人。

基本原理

那么，这个提案是否解决了前面提到的任何问题？

  1. 不再需要项目结构完整。一些开发人员处理树的非常具体的部件，而另一些开发人员几乎处理所有部件；两者都不应该被塞进临时项目结构中。此外，应该很容易在需要时创建新项目（并在不需要时删除它们），此提案应该能够做到这一点。

  2. 通过让成员定期选择项目负责人，项目负责人自然需要对项目成员至少负有一定责任（并希望能够积极响应）。本提案删除了项目负责人应满足的责任清单，因为自清单编写以来几乎没有人看过它。取而代之的是，负责人的实际职责是“满足成员的要求”，如果未满足，成员可以更换新的负责人（如果他们能找到愿意承担此职位的人！）。
  3. 如果委员会在处理全局问题方面做得糟糕（或没有全局视野），就投票罢免他们。
  4. 由于每个人都能够投票选举委员会成员，至少在原则上，委员会成员代表所有开发者，而不仅仅是特定子集。
  5. 申诉流程应该使纪律执行既不那么反复无常，也更容易让人接受。
  6. 本提案无助于查找不活跃的开发者或项目。这确实不应该成为太大的问题。我们已经有一个脚本可以识别在特定时间段内没有进行 CVS 提交的开发者。至于停滞的项目，如果项目页面没有维护，则表示项目已停止，我们应该将其删除。这也可能实现自动化。一个更大的问题是人手不足的项目，但更强的组织性不一定是解决方案。
  7. 元错误项目是一个好主意。让我们这样做！添加一个有用的项目不应该需要“元结构改革”，尽管在当前系统中确实需要。有了这个提案，就不需要了。
  8. 本提案对 GLEP 没有任何说明。

此文档的更新

对本文件的任何重大更新（即更改其内容而非仅仅修复错别字或添加少量说明的更新）都需要所有开发者的投票。有资格投票的人是提案更新发布时所有的开发者。如果满足以下两个条件，则投票通过

  • 赞成票与反对票的比率至少为 2:1，并且
  • 赞成票数不少于有资格投票人数的四分之一。