跳至主要内容
The Apache Software Foundation
Apache 20th Anniversary Logo

ASF 词汇表

此词汇表简要描述了 ASF 和 Apache 项目中使用的一些组织术语。有关任何 Apache 的更多信息,请参阅/dev 文档社区开发项目


工件

作为过程结果创建的文件,通常是发布准备过程。

ASF

Apache 软件基金会,一个非盈利组织。

阁楼

用于已停止、已放弃和已停用的代码库项目的位置。Apache Attic 项目为了后代、参考和潜在的未来重新激活而保留信息,同时将其与活动工作明确区分开来。

董事会

ASF 的九人法律管理机构,由成员选举产生。董事会负责监督基金会的活动和运营,并应用和执行 ASF 的章程。除其他事项外,董事会批准或拒绝提交给它的决议,例如创建或解散 ASF 项目、资金请求、法律问题和纪律处分。作为一家开放的非盈利公司,ASF 将董事会会议记录公开发布在https://apache.org/foundation/records/minutes/。这些记录包括所有未在执行会议中做出的决定。另请参见董事

自行车棚论证

(毫无意义地)争论用什么颜色粉刷自行车棚。如此处所述,当争论过于琐碎,以至于任何人都很容易有自己的意见,并希望自己的意见占上风时,可能会发生这种情况。

构建

**构建**是指不适合向公众发布的软件包。构建是正在进行的工作,并且应该仅供基金会从事产品开发的人员使用。

章程

章程是对组织遵循的规则的编纂。有些,例如ASF 章程,具有法律约束力,并在组织外部具有重要意义。其他,例如Jakarta 章程,仅在社区内具有意义,并且仅与其本身所赋予的约束力一样具有约束力。ASF 内部组织的章程不得与 ASF 本身的章程相矛盾;组织章程中任何此类冲突的部分必然无效。

主席

1. ASF 董事会主席,负责董事会的有序会议和运作。2. 委员会的正式负责人,例如项目管理委员会PMC。PMC 主席是 ASF 的副总裁,负责其项目的正常运作。

代码库

有意义的源代码组。一些项目仅使用单个代码库,而其他项目则有多个。

提交访问权限

ASF 项目使用版本控制软件协作编写代码以协调更改。直接更改该代码的能力称为提交访问权限(来自[VCS] commit子命令)。此过程修补实际的官方代码。另请参见Karma

提交者

有权直接提交对 Apache 代码库提交访问权限)的更改的个人。

先提交后审查

(通常缩写为“CTR”或“C-T-R”。)管理代码更改的策略,允许开发人员随意进行更改,并且可以追溯地否决更改。C-T-R 是通过惰性共识进行决策的应用。C-T-R 模型在快速原型环境中很有用,但由于缺乏强制审查,因此在日常实践中可能比R-T-C替代方案让更多的错误通过。比较R-T-C,并查看投票过程的描述。

社区

具有共同目标的个人群体。项目的社区由所有对该项目感兴趣的人组成。

代码之外的社区(以前称为 ApacheCon)

ASF 的官方开发者和用户大会(参见代码之外的社区网站)。

共识批准

“共识批准”是指已完成且**至少有三个有约束力的 +1 票**且**没有**否决票投票(意思 1)。比较多数批准

贡献者

ASF PMC下实体(代码或文档等)进行持续改进的人。这本身并不意味着提交访问权限,尽管频繁且有价值的贡献者很容易被投票获得此类访问权限。

贡献者许可协议

贡献者许可协议 (CLA) 有时也称为个人贡献者许可协议 (ICLA)。还有一个企业贡献者许可协议 (CCLA)。所有这些都在许可证页面上进行了说明。

CTR、C-T-R

参见先提交后审查

CVS

并发版本系统,一种较旧的版本控制系统

达尔文主义

参见软件达尔文主义

开发者

以代码或文档形式为项目做出贡献的用户成为开发者。他们采取额外步骤参与项目,积极参与开发者邮件列表,参与讨论,提供补丁、文档、建议和批评。开发者也被称为“贡献者”。

董事

每年由成员选举产生的九名基金会董事会成员之一。董事可能或可能没有个人职责,但通常都期望他们尽可能了解基金会的运营和活动,因为董事会负责监督整个基金会。

荣誉

用于正式指定某人不再活跃,但仍有权享受该职位的大多数权利和特权的术语。例如,长时间未参加任何会员会议的 ASF 会员被宣布为荣誉会员;不再有时间处理特定项目的人员可以宣布自己为荣誉会员。荣誉地位表示兴趣而非活动,而不是辞职。

进化

通过逐渐积累小的变化来进步。Apache 项目的典型模式。比较革命

执行会议

董事会会议的一部分,涉及机密事项,因此不能公开记录。例如,薪资讨论、保密协议涵盖的领域、纪律处分和某些类型的资金决策。

Git

大多数 ASF 项目使用的版本控制系统

黑客马拉松

ASF 参与者可以聚在一起、建立人脉并根据自己的兴趣讨论/争论/黑客/原型设计的非正式活动。黑客马拉松向所有提交者和受邀贡献者开放,通常在ApacheCon活动之前或之后立即举行。

冬眠

代谢率降低的类似睡眠的状态。有时用于描述活动水平低的项目

孵化器

孵化器为希望进入 ASF 的项目提供服务。

它帮助这些进入孵化器的新项目(称为“子项目”)采用 Apache 的治理和运营风格,并指导他们使用 ASF 为项目提供的服务,以便它们能够成为顶级 ASF 项目(“TLP”)。

IPMC

孵化器 项目管理委员会

由于 Apache 孵化器本身也是一个顶级 ASF 项目,因此它也拥有自己的 PMC。

IPMC 成员可以担任子项目导师

Karma

1. 执行操作的足够权限,例如提交对版本控制的更改。(“请授予 Yo Mega 对 foo-bar 的 karma。”)2. 社区中的尊重和功绩。(“Al Faa 和 Ro Main 因为他们提出观点的方式谨慎而得体,以及他们做出的技术贡献的质量而拥有良好的 karma。”)3. 含义 1 和 2 的任意组合;它们间接相关。

惰性共识

(也称为“惰性批准”。)一种决策策略,假设如果在定义的时间段内没有发布任何回复,则表示普遍同意。例如,“如果在未来三天内没有人反对,我将通过惰性共识提交此内容。”另请参阅共识批准多数批准以及投票流程的描述。

许可证头部

代码文件顶部的文本,引用该文件的许可证(而不是包含完整的许可证文本)。

多数批准

指的是投票(含义 1),该投票已完成,且至少有三个具有约束力的 +1 票,并且 +1 票多于 -1 票。(,简单的多数票,最低法定人数为三票)。请注意,在需要多数批准的投票中,-1 票仅仅是反对票,不是否决票。比较共识批准。另请参阅投票流程的描述。

导师

也称为“孵化器导师”。

孵化器为每个子项目委派一些导师,充当与各个 ASF 团队的联络员:孵化器 PMC、基础设施团队等,并促进子项目的成长和运营。

成员

ASF 使用此术语三种方式,因此除非上下文使其很明显,否则务必指定您的意思。

  • 由现有成员选举加入 ASF 的个人。ASF 会员权益包括在基金会的运作中拥有发言权,以及提名和投票选出新的会员候选人和董事。许多作者在以这种意义使用“成员”时将其大写。
  • 顶级项目或孵化器项目管理委员会的成员。
  • 项目社区工作做出贡献的个人。这个人可能是 ASF 会员、PMC 成员、两者兼而有之或两者皆非。
功绩

“功绩”的概念是 Apache 理念和社区方法的核心。功绩是一个定性和主观的术语,指的是一个人成就的价值和其同行的尊重的结合。

  • 技术能力
  • 与他人相处的能力
  • 对讨论和代码的积极贡献

获得功绩是一个累积的过程;一旦获得,它就不会衰减。但是,通过违反社区道德、准则或敏感性,可能会失去功绩。

精英统治

精英统治是 ASF 及其理念的底层原则之一。正如人们所说,“你做得越多,你被允许做的就越多。”当一个人获得功绩时,他们在社区中的地位以及(在某种程度上)对他们意见的重视程度都会提高。

网络礼仪

网络礼仪是良好的在线行为的通用规则。对于一般情况,它在IETF RFC 1855中定义;对于更具体的 Apache 环境,它归结为以下几点:

  • 不要辱骂
  • 加入列表后先潜伏一段时间再发帖;这使您可以了解个性、态度和问题,以及现有可接受行为规则。
  • 了解项目的/列表的指南(例如关于投票),不要违反它们。
  • 如果您有疑问,请在提出可能已得到解答的问题之前搜索列表存档和错误数据库。

这些只是可能在每个列表的基础上成为规则(或多或少)的大致轮廓。它们归结为“要有礼貌”和“不要为他人造成不必要的工作”。

NOTICE 文件

软件发布包中的 NOTICE 文件保留用于某些需要法律通知的子集,这些通知既不满足 LICENSE 文本的规定,也不满足捆绑依赖项中嵌入的许可信息的存在。请参阅NOTICE 修改以及Apache 许可证的第 4d 节。

官员

由 ASF 董事会任命并被赋予对基金会某些活动的部分特定权力和责任的个人。官员可能是也可能不是基金会的董事

包(有时非正式地称为 Tarball 或 Distribution)

是从项目的源代码创建的压缩存档文件,旨在进行分发。包通常是源代码包或从源代码构建的二进制包;有时会将单独的文档包与源代码包一起发布。通常,包具有外部依赖项,可能需要安装其他软件作为先决条件。

PEO

专业雇佣组织

PMC

项目管理委员会,负责项目的正式监督的人员组。PMC 主席始终是基金会的官员。由于 PMC 承担了由董事会分配的正式监督责任,因此其行为被视为代表基金会,并隐含所有法律保护和责任。请参阅章程

避免将 PMC 的成员称为“PMC”,因为它可能会导致混淆,即您是在谈论该组还是个人。

子项目

正在孵化的代码库及其社区。请参阅孵化流程的描述。

PPMC

子项目项目管理委员会,负责子项目的正式监督的人员组。

PPMC 没有主席。它在IPMC的监督下运行,尤其是子项目的导师

主席

ASF的主要执行官,在董事会的指示下工作。

项目

在 Apache 软件基金会中,“项目”一词通常指的是一个专注于一个或多个代码库社区,由PMC监督。

发布候选版本

要检查的源和其他伴随的工件,以查看它们是否已准备好发布。然后,PMC 投票决定是否发布候选版本。

发布经理

负责将发布引导至最终分发版本的发布流程中的个人。任何项目提交者都可以担任发布经理。通常缩写为“RM”。

审查后提交

(通常称为“RTC”或“R-T-C”。)提交策略,要求所有更改在提交到代码库之前获得共识批准。比较C-T-R,并查看投票流程的描述。

革命

在 Apache 环境中,一些社区可能会决定允许(或鼓励)革命作为调解分歧的方式,特别是那些在特定分支上因否决而被阻塞的代码更改。最初由 James Duncan Davison 在他的“革命者规则”中描述,该概念已被至少一个 Apache项目正式或非正式地采用。从本质上讲,当一组提交者决定派生当前主分支以处理有问题的代码或概念时,就会发生革命。这允许他们在不干扰主分支上的演化工作的情况下继续进行。革命性分支最终可能会合并回主分支、消亡、完全拆分并成为新的主分支,或者可能会将当前主分支吸收到自身中(基本上与第一个选项没有什么区别)。请参阅“革命者规则”并比较演化

发布

发布是由 Apache 软件基金会提供给公众的包。

RTC、R-T-C

请参阅审查后提交

软件达尔文主义

一个看似简单的概念,通常表达为“最好的代码生存”。Apache同行评审环境中固有的演化过程支持了这一理念。

软件赠予协议

参见SGA的详细信息

STATUS 文件

由于大多数Apache开发项目都采用非交互式通信方式,因此维护对已做和正在进行的决策的记录是一件有益的事情。一些Apache项目通过使用一个文件(通常命名为STATUS)来实现这一点,该文件存储在项目的代码库中。除了让现有开发人员了解当前问题外,此类文件还为正在调查该项目的新潜在开发人员提供了有用的信息。

STV

单一可转让投票,例如在Apache董事会选举中使用。参见http://en.wikipedia.org/wiki/Single_Transferable_Vote

Subversion

一个版本控制系统,它是“CVS 的一个极具吸引力的替代品”。少数项目使用Subversion (SVN)。

SVN

参见Subversion

搁置

在董事会会议记录中可能会看到“搁置”一词。例如,“特别议案7H,…,被搁置。”在这种情况下,它表示“推迟”或“延期”。

TLP

顶级项目,另请参见PMC

财务主管

ASF 的财务主管是该公司的官员,负责管理基金会的资金和资产,报告税务信息等。财务主管不必是基金会的成员,也不必是董事,尽管该角色通常由基金会的成员或董事担任。

喷子

一些定义

关于如何处理喷子,请参阅此线程,但(对于那些没有耐心的人)这里有Ted的意见(它作为很好的总结)。

用户

使用我们软件的人。用户通过以错误报告和功能建议的形式向开发人员提供反馈来为Apache项目做出贡献。用户通过在邮件列表和用户支持论坛上帮助其他用户来参与Apache社区。

版本控制系统

版本控制系统提供了跟踪(并可能恢复)文件增量更改的功能,在更改时将其报告给邮件列表,并且可以由许多开发人员同时使用。基金会的所有代码和文档都在此类系统中管理,从而为每个代码库提供了完整的历史记录。参见GitSubversionCVS

否决

根据Apache方法,对所做或提出的更改可以通过提交者对相关代码库行使否决权来阻止。如果R-T-C提交策略生效,则否决将阻止更改。在R-T-C或C-T-R环境中,应用于已完成更改的否决将强制其恢复。否决权不得被覆盖或否决,并且只有在发出否决权的提交者撤回时才会失效。所有否决权必须附带有效的技术理由;没有此类理由的否决权无效。如有疑问,PMC负责决定技术理由是否有效。否决权会促使讨论,并在得到支持的情况下,进行版本控制回滚或相应的代码更改。最好由原始提交者恢复被否决的代码提交,除非需要紧急解决方案(例如,构建中断)。否决权仅适用于代码或文档更改;它们不适用于软件发布等程序问题。

副总裁

ASF 副总裁是公司的官员,负责基金会工作的特定领域。 PMC 主席是负责其项目正常运行的副总裁。

投票

1. 做出正式决定的过程。(“foo的投票将在三天内结束。”)

2. 作出正式决定时表达肯定或否定意见或否决权。(“我的投票是-1,因为foo闻起来很糟糕。”)

具有约束力的投票是指PMC提交者针对相关项目做出的投票。其他人投出的票仅供参考或指示。
另请参见共识批准多数批准惰性共识以及投票流程的说明。