转自：http://www.javafxchina.net/blog/2016/01/eclipse-policy-02-eclipse-development-process/

每日必读的精华社区构建指南！

这篇文档描述了Eclipse基金会的开发流程。特别描述了大规模的成员、董事会、这个生态系统的其他部分，以及为了达到这些Eclipse目的，Eclipse管理组织（EMO）对Eclipse项目的领导、影响并与之合作。

Eclipse科技公司是一个中立的厂商，是开放式开发平台，并提供框架，范例和扩展工具（Eclipse平台）。Eclipse平台工具集是典型的验证有效的Eclipse框架集，并说明（如何）恰当地使用那些框架集，并且对Eclipse平台本身提供开发和维护；Eclipse平台工具集在功能上是可扩展的，并通过文档化的可编程接口来访问。Eclipse基金会的目标是提升创造性，进化性，提升性，支持Eclipse平台，并培育其开源社区和能够产品、能力和服务方面互补的生态系统。

本文档包含如下章节：

● 准则：概述了开发流程所依据的基本准则。

● 需求：描述了Eclipse社区的开发流程的需求。

● 结构和组织：指定了Eclipse项目和项目团体的结构和组织。

● 开发流程：概述了所有Eclipse项目要求的生命周期和流程。

2. 准则

以下内容描述了用在开发流程方面的指导准则

2.1 约定的开源规则

开放 – Eclipse对所有人开放；Eclipse对所有人提供同等的机会。每个人在同样的规则下参与；对于潜在的捐助者，包括市场的直接竞争者，均没有例外。

透明 – 项目讨论、会议记录、研究、项目计划、新功能计划以及其他产品都是开放的、公共的并且是容易获取的。

精英制度 – Eclipse是精英制度。贡献越多，你得到的责任越多。在Eclipse中的领导角色基于精英制度并来源于同行肯定。

2.2 ECLIPSE生态系统

Eclipse作为其所有部分（所有项目）总和的一个品牌，所有项目均需尽最大努力做到最高水准，包括可扩展框架、范例工具、透明流程和项目开放性等方面。

Eclipse基金会有责任去培育一个在产品、能力和服务方面互补的生态系统。因此Eclipse开发流程保证了一个重要准则，即项目管理是为了开源组织和生态系统成员的利益。为此目的，所有Eclipse项目都需要：

● 定期以开放和透明的方式发布项目计划和新特性计划（无论大小）；

● 创建能够支持商业级产品的平台质量框架

● 为广大社区用户提供可扩展的范例工具。

2.3 三个社区

围绕每个项目发展三个相互依赖的社区是达成Eclipse基金会目的必要条件。

2.3.1 捐助者和提交者

一个旺盛的、多样化的、活跃的开发者社区是所有Eclipse项目的关键部分。理想情况下，这个社区应该是一个提交者和（非提交者）捐助者的开放的、透明的、包容的、多样化的社区。对于一个开源项目，吸引新的捐助者和提交者是耗费时间的，并需要持续的招募，而不仅仅是消极的“开放”。项目领导者必须付出一定的精力鼓励和培养有前途的新的捐助者。

2.3.2 用户

一个积极参与的用户社区有效证明了项目的范例工具是有用的且是必要的。此外，一个大型的用户社区是创建一个围绕Eclipse项目的可行的生态系统的关键因素之一，因此要鼓励其他开源和商业组织的参与。像其他的美好事物一样，一个用户社区需要耗费时间和努力去培养，但是一旦成型之后通常就可以自给自足。

2.3.3 采纳者

一个积极参与的采纳者/插件开发者社区是证明Eclipse项目正在通过文档API提供可扩展框架和工具的唯一方法。在对项目正在贡献的公司中，框架的重用是必要的，但是并不说明这就是一个采纳者社区。其次，在项目的开发者之外创造、鼓励和培养一个采纳者社区是需要时间精力，和项目领导者的创造力的，但是对于项目长期开源的成功是必须的。

Eclipse社区认为，这些社区其中缺少任意一个，都证明项目不够开放、透明和诱人，而且/或者证明了在牺牲可扩展框架的情况下强调了工具，或者反之亦然。

2.4 清晰，简明与进化

开发过程需要尽量清晰简明，这是一个明确的目标，这可以帮助项目团队有明确的方向，避免弯路，并尽快成功。

这篇文档规定了项目运转的需求和限制，并代表了广大的Eclipse社区的利益。在开发过程中提供尽可能多的自由和自主，同时也要确保整个Eclipse社区的利益，这是一个明确的目标。

同样，本文档不应对EMO或董事会有过分的约束，为了防止他们必要的控制过程。我们不能预知所有的情况，因此应当谨慎地规定和/或需要通用的一些指标。

框架、工具、项目、进程、社区，甚至是质量的定义也是如此，并且持续发展进化。创立死板的规则或流程是不利于Eclipse社区健康、生态地进行发展。

本文档的部分效力并不在于说了什么，而是通过会议、指南和公共咨询等进行社区定义。一个有太多结构的文档会显得太死板，并会妨碍Eclipse的进化和改变。在某些方面这篇文档比较模糊，我们希望项目和成员积极参与到大社区中，使得当前的标准和期望更加清晰。

3. 要求

这篇文档和其他附加的标准由EMO创立，包含了要求，建议和意见。

要求 – 在Eclipse开源项目中，参与者需要承担一定的责任与行为（义务）。那些没有执行必要行为的项目将由EMO终止。在保持指导原则的前提下，尽可能减少要求的数量。

准则 – 被建议为最佳实践的其他责任和行为。总的来说，我们知道如果团队成员和领导者都遵循这些建议，则项目最有可能获得成功。我们强烈鼓励项目都遵循这些建议，但是如果不这样做，也不会受到惩罚。

3.1 要求和指导

本文档都由要求组成。除了在开发过程中的要求以外，EMO通过创建一系列Eclipse项目开发准则指导阐明、详述并扩展这个过程，以推进对Eclipse平台的创造、进化、提升和支持，并培育出开源社区以及产品服务互补的生态系统。

如果没有董事会的书面确认，EMO不允许更改或忽略本文档列出的要求

4. 项目结构和组织

项目是Eclipse基金会的主要操作单元。具体地说，即所有Eclipse基金会的开源软件开发都是在某个项目的上下文中进行。项目有领导者、开发者、代码、发布版本、下载、网页以及其它内容等。项目不仅仅是这些部分的总和，当提供给开发者、采纳者和用户社区时，项目也是开源工作的组织方式。项目提供了帮助开发者向广大用户展示他们辛勤工作的安排。

Eclipse基金会的项目的组织是分级的。 “顶级项目”作为一种特殊类别的项目，处在各级的顶端。每个顶级项目包含一个或多个项目。每个项目可以包括零个或多个项目。包括了一个或多个项目的项目被称为这些被包含项目的父项目。一个拥有父项目的项目通常被称为一个“子项目”。项目如果不是一个顶级项目，那么就是一个子项目。

一个项目的后代是项目本身和其子项目的传递闭包。一个项目的顶级父项目是位于层级顶端的顶级项目。

项目是以下内容的单元实体：

● 提交者

● 代码和发布版本

● 知识产权记录

● 社区意识

根据Eclipse基金会章程（Bylaws of Eclipse）-第七章的定义，“Eclipse管理组织”（Eclipse Management Organization，简称EMO）由Eclipse基金会成员和委员会组成。当讨论一个审批流程时，术语EMO（ED）表示EMO的子集，其中包括执行董事以及能代理其指定审批权限的人。

4.1 提交者

每个项目都有一组提交者。每个项目的提交者组都不同于其它项目，包括子项目和父项目。所有项目的提交者都有同等的权利和义务。项目中的责任划分根据社区约定来管理。例如，一个项目可能根据功能的逻辑分区来划分；这个社区约定是防止一个逻辑分区的提交者去做另一个逻辑分区的不合理的工作。如果需要更细致地管理提交者的责任，则一个项目需要考虑（通过重组评审Restructuring Review）分为两个或多个子项目。

项目的提交者拥有选择新提交者的特权；其它组包括父项目均不能强迫一个项目接受一个新的提交者。

提交者不可越级:一个项目的提交者都被明确选出在对应项目中担任角色（即子项目的提交者没有被自动授予在其父项目或其子项目中的权限）

在实际情况中，每个项目在其提交者中都有一个独立的UNIX组，他们具有对项目资源的写入权限。如下所述，我们看到一个项目，除了拥有多种资源和提交者之外，还可以具有零个或多个子项目。每个子项目拥有其独立的提交者和资源。

4.2 代码和资源

每个项目都拥有并维护了一批资源。

资源可能包括源代码、项目网站、下载服务器空间、构建资源的权限、以及其它由Eclipse基金会基础设施提供的服务。由Eclipse基金会提供的基础设施详情会随时间变化并会在本文之外进行定义。

一个项目并不严格要求确保所有资源都可用；例如一个项目可能并不会维护一个源代码库。这样的项目对于一些子项目而言，可能会作为一个组织单元，或者容器来运作。类似地，一个项目可能会为其子项目提供一个统一网站，版本和/或下载站点（子项目可能自身就不再需要这些资源了）。

EMO会为项目分配命名空间。所有项目源代码必须在指定的命名空间下管理，项目只能在其自己命名空间下发布代码（即不能侵犯另一个Eclipse项目的命名空间）。项目必须与PMC和EMO协同工作来处理本规定的例外情况，如果对命名空间的使用有问题，请咨询导师和PMC。

4.3 知识产权（IP）记录

任何等级的项目都可能收到贡献者和第三方库的IP许可。IP核准通常包括对所有后代项目的同样核准。然而，IP许可只能在最合适的技术水平上被授予。

4.4 社区意识

项目是与更大的Eclipse社区和生态系统进行沟通的层级。项目可以有自己的沟通方式（网站、邮件列表、论坛/新闻组，等等）或者可能是其父项目的沟通方式（网站、邮件列表、论坛/新闻组，等等）的一部分。在这两种情况下，项目都需要维持与Eclipse社区的一个开放、公开的沟通渠道，包括但不仅限于项目计划，时间表，设计讨论。

所有项目都应确保沟通渠道容易被找到。项目后续需要使其子项目各自的沟通渠道也容易被找到。

任何在孵化阶段的项目必须正确地标识出其网站和发布版本。如果一个项目拥有至少一个在孵化阶段的后代项目，则它必须正确地在其网站上进行注释说明以便通知Eclipse社区表示在其项目等级中存在孵化中的项目。任何包括有孵化阶段的项目代码的发布版本必须被正确地标记出来，例如，孵化阶段是病毒式的并会扩展到覆盖所有的发布版本中。

4.5 范围

每一个顶级项目都有一个项目章程来描述其目的、范围和操作规则。项目章程应该参考本开发流程的条款 ，并且应描述与对应条款相关的详情。董事会审批每个顶级项目的章程。

子项目没有单独的章程；子项目都在其顶级父项目的章程下运作。

所有项目都要有一个明确的范围，项目中的所有提议都需要包括在该范围内。如果发现在项目范围之外的提议和代码可能会导致项目的终止。顶级项目的范围是章程的一部分，由Eclipse基金会的董事会审批。

一个子项目的范围由初始项目建议书定义，并由该项目的顶级父项目的项目管理委员会（PMC）（如后文定义）和EMO审批。一个项目的范围必须是其父项目范围的子集。

4.6 领导者

在Eclipse基金会中有两类项目领导者:项目管理委员会（PMC）和项目领导组。两种形式的领导者都需要：

● 通过引导总体方向和克服障碍、解决问题、化解冲突等手段来保证项目的高效运作；

● 使用开源准则来运作：精英参与，透明性，和开放地参与；

● 确保项目和其子项目（如果有的话）遵守Eclipse基金会的知识产权政策和规程。

一个项目的领导链由该项目的项目领导（组），父项目的领导者（如果有），顶级项目的PMC领导和PMC成员，EMO，和EMO（ED）组成。

在例外的情况下–例如项目没有活跃的提交者，有破坏性的提交者，或者没有有效的项目领导–项目领导链有权改变（增加或删除）项目的提交者组和/或项目领导，并且还可以代理项目领导开展工作。

4.6.1 项目管理委员会（PROJECT MANAGEMENT COMMITTEE，PMC）

顶级项目由项目管理委员会（PMC）管理。一个PMC有一个或多个PMC领导以及零个或多个PMC成员。PMC共同为在顶级项目之下的项目们提供全面监管。PMC作为一个整体，特别是PMC领导，对确保项目了解和遵循Eclipse开发过程负有最高责任。另外PMC还负责维护顶级项目章程。

PMC领导由董事会审批；PMC成员由现有的PMC领导和成员选举，并由EMO（ED）审批。

4.6.2 项目领导

Eclipse项目被一个或多个项目领导管理。项目领导负责确保该项目的提交者遵循Eclipse开发过程，并确保项目正在从事正确的活动以发展活跃的用户、采纳者和贡献者社区。最初的项目领导在创立评审时进行任命和审批。随后，其他的项目领导必须由项目提交者选举并由项目的PMC和EMO（ED）批准。

在一种不太可能的情况下，项目领导成为了过程的破坏者，或者长时间停止了贡献，则该项目领导可以通过其余项目领导（至少有其他两名项目领导）全体一致投票被免除，或者通过项目PMC的全体一致投票被免除。

4.7 提交者和贡献者

每个项目都有一个由项目领导者带领的开发团队。开发团队由提交者和贡献者组成。贡献者是提供代码、问题修复、测试、文档或项目其它工作的人。提交者有项目资源（源代码库、bug 跟踪系统、网站、构建服务器、下载包等等）的写入权限， 并能影响项目的开发。

获得项目提交者信任的贡献者通过选举可以被晋升为项目提交者。提交者的影响力与其作出的贡献度一致。一个开发团队的提交者和贡献者可能（并且应该）来源于不同组织。提交者具有可以影响项目未来发展的选举权。成为提交者是一种特权，这种特权源自作出的贡献以及展现出的纪律性和良好的判断力。这是一种责任，既不应被轻易赋予或剥夺，也不应该是一种基于Eclipse成员公司或其他公司对现有提交者的雇佣关系之上的一种权力。

选举过程首先是在同一项目中的现有提交者对贡献者进行提名。项目的提交者们将在不少于一个标准工作周的时间内进行投票。如在投票期间没有反对票，并有不少于三个赞成票，则该贡献者将被推荐给PMC以授予提交特权。如果项目中只有三个或更少的提交者，则需全体通过。如PMC审批通过，则贡献者需签署由EMO制定的正式提交者法律协议（其中至少要求开发者同意遵守Eclipse 知识产权政策），然后贡献者便可成为提交者并会被授予对项目源代码的写入权限。

有时，由于各种原因提交者们可能会变得不太活跃。项目的决策过程依赖于活跃的提交者们，他们积极响应讨论，及时而富有建设性地投票。项目领导者应该确保项目的平稳运行。那些破坏，不积极参与活动或长期不活跃的提交者则会被项目领导将撤销提交者状态。如无特殊说明，这里指的“长期”表示“六个月以上都没有活动”。

在用户沟通渠道和适当的开发者邮件列表中积极参与是所有提交者的责任，也是项目成功的关键。提交者被要求对用户沟通渠道进行监督并做出贡献。

提交者被要求监督与项目有关的邮件列表。这是被授予项目提交权限的一种情况。这是一种强制性要求，因为提交者必须参与投票（在一些情况下需要一定的最小投票数）且必须及时回应邮件列表以帮助项目顺利运行。当提交者被赋予提交权限时，他们会被加入到适合的邮件列表中去。提交者必须不能从开发者邮件列表中被取消订阅，除非他们的提交特权也被撤销了。

提交者必须对其相关项目中的相关讨论进行跟踪、参与并投票。投票结果有三种：+1 (赞成), -1 (否定, 或否决), 和0 (弃权)。

提交者应负责在bug跟踪系统中主动报告问题，并且对问题报告进行说明，包括状态信息、解释、澄清，或者从问题提交者那里获取更多信息。提交者应负责在问题相关工作处理完毕后更新问题报告。

提交者、PMC领导或成员、项目领导、委员会代表都是其中的角色；个人可以同时担任其中的一个或多个角色。

4.8 委员会

委员会在章程第七节中定义，由战略伙伴和PMC代表组成。委员会按如下信息来帮助指导项目：

● 计划委员会负责建立一个协调同步的发布版本（又名：发布列车，The release train）。计划委员会也要负责跨项目计划、架构问题、用户界面冲突，以及其它协调和集成方面的问题。计划委员会通过相互评估、优先秩序、妥协等各种方式履行职责

● 架构委员会负责：（1）监控、指导并影响项目使用的软件结构；（2）新项目指导；（3）维护并修订Eclipse开发过程。架构委员会的成员根据章程通过战略成员，PMC和任命来产生。架构委员会至少每年一次向EMO（ED）推荐有丰富经验、智慧和时间的Eclipse成员加入结构委员会并担当导师。被选举成为一名导师是Eclipse社区对候选者的尊重的高度肯定，这种尊重包括对候选者的技术视野、良好的判断能力、软件开发技巧、过去与未来对Eclipse的贡献。这种角色不会被轻易授予或剥夺。架构委员会成员的任期为两年。

4.9 永久孵化器项目

一个项目可能指定一个子项目为“永久孵化器”。一个永久孵化器是一个永远保持在孵化状态的项目。对于创新、测试新想法、发展将来可能用到另一个项目中的功能、开发新提交者等来说，永久孵化器是一个绝佳的地方。

永久孵化器项目永远不会发布；它们不参与年度同步发布。永久孵化器可能有构建版本与下载。它们遵守标准孵化器商标要求，并遵循孵化器项目的IP尽职准则。永久孵化器永远不会毕业进入成熟状态。

永久孵化器项目的范围必须在其父项目范围之内。永久孵化器项目的提交者组必须与父项目的提交者组有交集（至少一个父项目的提交者是孵化器项目的提交者）。永久孵化器项目不需要架构委员会导师（父项目的提交者对确保孵化器项目遵循Eclipse开发过程负责）。

永久孵化器项目必须指定一个包含“incubator”（孵化器）一词的名字（如：Eclipse Incubator）。如果不这么做会被视作特殊情况并且需要由PMC和EMO(ED)审批。

只有顶级项目和处于成熟阶段的项目可以创建永久孵化器。永久孵化器项目可以按需创建，无需创建评审。

5. [保留]

6. 开发过程

项目必须在其范围内运行。当项目希望扩展其当前的范围时，必须根据下面所述的公开评审来探讨其扩展范围。此外，项目必须与包含它的项目定义的范围匹配，并且也必须与其顶级项目的章程定义的范围匹配。

项目必须通过项目计划来提供即将发布的特性和框架的提前通知。

6.1 导师

新项目建议书需要包括至少两名导师。导师必须是架构委员会成员。导师必须在建议书中列出。导师需要在项目处于孵化阶段时对项目进行监管与建议；一旦项目毕业进入成熟阶段，则导师对应职责结束。

6.2 项目生命周期

项目会经历不同的阶段。在不同的阶段之间的过渡通过公开、透明的公开评审进行。

6.2.1 预案期

个体或者个体组成的团体宣布他们有兴趣、并且有理由建立一个项目。EMO将协助这样的团体来准备项目建议书。

6.2.2 提案期

提案者与目标PMC和社区合作，共同完善、提炼以及明确提案。项目导师必须在这一阶段确定。

6.2.3 孵化期

孵化阶段的目的是为了建立一个全功能开源项目。在这种情景下，孵化从事于发展流程、社区和技术。孵化是一个阶段而不是一个位置：新的项目可能在已存在的项目之下孵化。

● 一个在孵化期的项目可以（并应当）发布版本；

● 顶级项目跳过孵化期并直接进入成熟期；

● 当通过毕业评审或终止评审时孵化期结束；

● 指定的永久孵化器项目永久维持在孵化期；这些项目不发布版本，所以也不必审查；

许多Eclipse项目由具有丰富和成功软件开发经验的个人提出并发起。本文尝试定义一个足够灵活的流程来从向所有的参与者学习。与此同时，孵化阶段对新项目去学习由社区定义的以Eclipse为中心的开源过程也非常有用。

只有被正确地认定处在孵化期的项目（包括指定的永久孵化器项目）才可以使用并行IP过程来缩短对新贡献者的IP许可过程。

6.2.4 成熟期

项目团队已经展示出他们是一个具有公开和透明过程的开源项目；具有一个积极参与和成长的社区；具有Eclipse品质（Eclipse-quality）的技术。项目此时是Eclipse社区中的一个成熟成员，主要发布版本需继续通过发布评审。

6.2.5 [保留]

6.2.6 存档期

变得不活跃的项目，无论是通过逐渐减少资源还是自然而然地终结，都要被存档。项目可以通过多种方式自然而然地终结：例如，一个项目可能变得非常流行，因此被其它主流框架之一吸收。项目通过终止审查变为存档状态。

如果有一个有能力的社区对重启一个已存档的项目感兴趣，项目可以通过创建评审来重新开启。由于终止项目一定有足够合理的理由，因此创建审查需要提供足够高的门槛来证明那些理由都不再有效。

6.3 评审

Eclipse开发过程建立在公开和透明的行为之上。所有Eclipse项目的重大变更都必须由广大会员宣布和评审。重大变更包括项目阶段改变，以及重要新技术或功能的引入与排除。本文档中明确要求那些正在关注着媒体渠道（例如邮件列表或RSS源）的成员不会因项目的事后行动而感到惊讶。

对于每一个评审而言，项目领导者要为Eclipse成员准备文档，并接收相应反馈。

评审是一个相当广泛的过程。收集评审材料和准备文档需要做出很大努力，但是它提供的反思对项目很有用，并且评审结论对整个Eclipse社区也是非常有用的。另外，评审与Eclipse IP政策的要求有特定的关系。

所有评审通常包括以下步骤：

1 . 项目负责启动合适的评审。然而，如果一个项目不这样做但EMO坚信评审是必要的，则EMO可以基于项目启动一个评审。

2. 随着项目领导要求EMO（ED）安排评审，评审会继续进行。

3. 在评审期开始之前，项目领导要向EMO提供评审文档。

● 评审文档材料总是包括一个描述评审的文档，文档的最小内容根据各个评审类型指定。

● 评审文档必须是每个Eclipse成员都能评审的格式。PDF和HTML是可以接受的独立格式。

● 评审文档必须是档案品质（archival quality）。这意味着材料必须可理解且完整，不需要其他人员解释，不需要参考维基，也不需要参考其它未归档的网页。

4. EMO宣布评审安排并向广大成员提供文档。

各类评审成功完成的标准由EMO在Eclipse基金会网站的指南文档中写出。这些指南将包括，但不限于以下内容：

1. 根据评审类型，明确证据表明项目有活跃的提交者、采纳者和用户社区。

2. 根据评审类型，提交者群体具有合理的多样性。多样性状态不仅必须根据人员/公司的数量，还由这些人员/公司做出的努力。

3. 所有在Eclipse IP政策之下要求的尽职调查必须完整记录在案。

4. 对于毕业和发布评审，项目必须有一个当前的项目计划，格式由EMO指定，并提供给社区。

5. 在创建框架和可扩展的范例工具这两方面要平衡进行。

6. 通过项目团队选择的度量和策略来展示项目质量，如耦合度、环路复杂度、测试/代码覆盖度，扩展点文档等等。

评审期至少开放一个星期，通常在接受的工作日内不超过两个星期。

1. 评审开始于EMO发布评审材料，此时即作为审查期的开始。

2. Eclipse开发过程正常运作取决于Eclipse成员和提交者的积极参与，尤其是在评审中，因此每次评审都有一个由EMO指定的讨论和反馈交流渠道：一个论坛/新闻组，一个邮件列表，或者一个其他公共论坛。

3. 如果评审需要一个提交者选举(例如，一次创立评审)，那么将在评审期内同时举行。因此选举和评审将同时结束，使得结果项目可以得到快速高效地准备。

4. EMO（ED）基于公共评价、项目范围、章程定义的Eclipse基金会的目标来批准或拒绝评审。

5. 当在规定的评审交流频道中宣布结果时（EMO（ED）将要求项目领导来宣布），评审结束。

如果任何会员认为EMO在批准或拒绝一个评审时并不合理，可以向董事会投诉来评审EMO的决策。

6.3.1 创立评审

创立评审的目的是评估社区和成员对提议的响应，验证项目要实现其计划具备的可利用的合适的资源，并作为项目初始提交者的一个提交者选举。Eclipse基金会一直努力不要成为一个“代码垃圾”的仓库，因此项目必须有充足的人手以向前推进。

创立评审文档必须包括被提议的初始提交者的简短提名简历。这些简历应当讨论他们与将要引入的代码和/或他们参与的被提案覆盖的领域/技术之间的关系、历程。目标是保持之前的贡献者与新项目之间的联系，并向当前与未来的Eclipse成员解释这种联系，并且证明初始提交者的参与是处于精英体制下的。

6.3.2 毕业评审

毕业评审的目的是为了标记一个项目从孵化器到成熟期的改变。

毕业评审确认项目具备了以下条件：

● 足够高质量的可运行并且可演示的代码。

● 与即将毕业的代码基数量级相匹配的活跃和足够多样的采用者，开发者和用户社区。

● 遵循Eclipse的准则和目的，充分开放地运作。；

● 对Eclipse信用良好，并在更大的Eclipse社区运行良好。

毕业评审通常伴随着发布评审。

6.3.3 发布评审

发布评审的目的是：总结发布的成果，验证IP政策都被遵循并且所有审批都已经通过，强调所有遗留的品质和/或结构问题，并证实项目会继续根据Eclipse的规则和目的来运作。

6.3.4 [保留]

6.3.5[保留]

6.3.6 终止评审

终止评审的目的是为了给提交者和/或Eclipse成员提供一个最后机会来讨论一个项目的存档建议。终止评审所期望的结果是发现关于新的兴趣和资源的充分证据，以此来继续保持项目的活跃。

6.3.7 [保留]

6.3.8 重组评审

重组评审的目的是向社区通知一个或多个项目的重大改变。“重大改变”的例子包括：

● 将重要功能从一个项目移动到另一个项目。

● 项目结构的变更，例如合并多个项目为一个项目，或者将一个项目拆为多个项目。

● 项目范围的变更。

6.3.9 联合评审

评审可以由PMC和EMO联合处理。多个项目可能参与同一个评审。类似的，多种类型的评审也可以同时进行。例如，父项目可以参加汇总发布评审，其中包括其本身以及父项目的部分或所有子项目；一次统一的重组评审可能将代码移动到几个项目中；一次发布评审可能与一次毕业评审结合。当联合多个评审时，评审文档必须明确陈述所有项目和评审的类型，也必须包括相关的所需信息。

需要注意的是联合评审的目的是为了更好的服务于社区，而不是减少项目的工作量（尽管幸运的是它确实做到了两者兼顾）。联合一个发布评审和毕业评审，或者将一个项目及其子项目的发布评审汇总在一起通常都是有意义的。一般不会对多个不相关的项目进行联合发布评审。

6.4 发布

除了永久孵化器以外的任何项目都会有对外发布。发布内容可以包括来自项目所有子项目的代码。

(Apache软件基金会发布FAQ（Apache Software Foundation Release FAQ）的内容非常优质，本章节大部分内容都是从它那里借鉴或改写而来。Eclipse社区与Apache社区在发布方面有很多相同的理念，并且Apache社区与其表述已经做得十分优秀。Apache软件基金会发布FAQ在Apache许可证2.0版（Apache License，Version 2.0）下发布。)

根据定义，发布是指分发到项目的提交者之外的任何内容。如果用户被引导下载了一个构建版本，那么这个构建版本就可以称为被发布了（除了下面描述的例外情况）。所有的项目和提交者在批准任何发布时都必须遵守Eclipse基金会的要求。

(例外1：每夜（Nightly）构建版和集成（Integration）构建版)在开发软件和准备发布的过程中，出于测试目的会向开发者社区提供多个每夜构建版和集成构建版。不要在项目网站、博客、维基等上包含任何相关链接，这可能导致非早期采用者（no-early-adopters）下载并使用每夜构建版、候选发布版或其它类似包（针对早期采用者（early-adopters）和项目开发者的链接都是被允许并且被鼓励的）。只有开发者邮件列表里的人才应当知道这些包的存在，因此他们才知道这些构建版的局限性。

(例外2：里程碑版和备选发布构建版) 鼓励项目使用包括定期里程碑的敏捷开发过程（例如六周里程碑）。里程碑和备选发布是期望给早期采用者使用和测试的“近似发布版本”。项目允许在项目网站、博客、维基等上提供链接，鼓励提交者圈子之外的早期采用者下载并测试这些里程碑版和备选发布版，但是必须附带警告解释这些并非官方发布版本。

● 里程碑版标记为yMz。例如2.3M1(2.3版本的里程碑1)，2.3M2(2.3版本的里程碑2)等。

● 备选发布版标记为yRCz，例如2.3RC1(2.3版本的备选发布版1)。

● 官方发布版都被标记为y，例如0.5，1.0，2.3等。

所有官方发布版在提供下载之前都必须有成功的发布评审。

(例外3：不带新功能的bug修复发布版)基于基础发布（例如2.3）的不带新功能的bug修复发布版（x.y.z，例如2.3.1）允许在没有额外的发布评审的情况下发布。如果一个bug修复发布版包含了新功能，则对应项目必须进行完整的发布评审。

在任何情况下构建版和里程碑版都不能替代官方发布版。正常的发布管理和评审是Eclipse品质（Eclipse Quality）的关键。

在孵化阶段的项目发布必须被标记以表明项目的孵化状态。

6.5 申述处理

当成员对项目存有疑虑时，成员可以向项目领导提出对应的疑虑。如果成员对于处理结果不满意，可以向父项目领导提出对应的疑虑。成员可以继续沿项目领导链上诉，如果对处理结果还是不满意，则可以由此转到EMO，然后是执行董事，最终到董事会。所有的上诉和讨论都会基于开放、透明和公开的指导准则进行处理。

成员的疑虑可能包括：

● 超出范围。有人认为项目超过了批准的范围。

● 功能异常。有人认为项目不正常运作或者违反一条或多条Eclipse开发过程的要求。

● 捐助者上诉。有人认为希望成为提交者的捐助者没有被公正对待。

● 不合理否决。有人认为在评审中的一次否定投票不符合项目和/或Eclipse的利益。

EMO对申诉的各种解决方案可以升级到，并且包括使用新的提交者和领导来重启或重新开始一个项目。

7. 优先权

当本文档与董事会批准的项目章程之间有冲突时，最近批准的文档将享有优先权

8. 修订

正如章程中所规定的，EMO负责维护本文档，所有变更必须通过董事会的批准。

由于Eclipse技术，Eclipse社区以及软件市场的不断进化，Eclipse开发过程（即本文档）应至少每年进行一次审查与修订。审查的时间线应当选择，以便包含前一年的协调发行的课程，并应用于下一年的协调发行。

EMO还需要用及时、有效的方式，确保与本开发过程相一致的计划、文档和报表以适当的机制提供给广大的会员。

8.1 修订2.7

本文档于（待定时间）通过了Eclipse基金会董事的批准。将于（待定时间）生效（替代之前所有版本）。

8.2 历史

略