Eclipse基础规范流程分步指南

科学进步“突飞猛进”？ –霍布斯

Eclipse Foundation Specification Process （EFSP）为从事规范制定过程的开发人员提供了框架和治理模型。

规范 ：规范是相关工件的集合。

EFSP将规范定义为“应用程序编程接口（API）定义，语义行为，数据格式，协议和/或其他参考规范的集合，以及其TCK，旨在支持开发和测试独立的兼容软件。实施。” 因此，规范项目是与一个或多个规范的创建和维护有关的Eclipse开源项目。

实际上，我们倾向于在规范项目和规范之间建立一对一的映射。 但是，有一些规范项目的示例可充当多种规范的宿主。 例如， 用于稳定Jakarta EE API的Eclipse项目是一些规范的宿主项目，这些规范被认为是稳定的并且可以长期维护（并且预计不会继续发展）。

规范项目 ：规范项目是由一组致力于创建和维护一个或多个规范以及创建这些规范所需资源的提交者组成的团队。

分配给规范项目的资源包括一个或多个软件存储库，这些软件存储库用作开发规范文档和相应技术工件的协作点。 规范项目还分配了其他资源，包括下载服务器上的空间，构建资源和邮件列表。

规范项目也可能负责其他相关功能，包括TCK。 将规范的实现与规范本身分开是一种最佳实践，但是没有防止这种耦合的规则。

一个规范项目有一个或多个项目负责人，他们通常也是提交者。 项目负责人在制定和交付规范方面没有特殊权力或权限。 相反，它们是项目团队与Eclipse Foundation之间的主要联络人，并且构成了包括项目管理委员会（PMC）和Eclipse管理组织（EMO）在内的领导链中的第一个链接。 首先，项目负责人负责确保项目团队（即提交者）遵守规则。

规范版本 ：规范项目生成规范的版本，EFSP将其称为规范版本。 批准后，规范版本将成为最终规范。

规范版本和最终规范之间的差异非常细微。 规范版本是开源项目的输出。 虽然可以说规范版本的最终版本是完整的，但不能将其用作实现的基础。 实施规范所需的知识产权贯穿最终的规范（稍后再详细介绍）。

EFSP并没有规定具体的包装或分发方式，但是可以将最终规范视为一个完整的软件包，其中包含规范文档的只读版本，技术工件（例如API），TCK和一个或多个。更兼容的实现。 同样，EFSP对如何打包所有内容没有特殊要求，因此，例如，TCK和兼容的实现可能表现为指针。

规范项目持续存在 ：规范项目是围绕一般意义上的制定和维护规范的思想而形成的。 同一规范项目将产生一个规范的多个版本。 在发布规范的最终版本和完整版本之后，项目团队将开始下一个版本的开发周期。

团队成员（即提交者和项目负责人）可以来去去去，但团队仍然存在。

规范项目具有定义明确的范围，该范围定义了其活动的边界。 项目制定的所有规范版本都必须包含在范围之内。

EFSP并未规定与规范项目相关的资源的结构，超出了规范项目必须是规范文档所在地的要求。 对于像Java®之类的具有技术工件（例如接口）的技术而言，这很方便，但不必将这些技术工件的源代码作为项目的一部分进行维护。

严格来说，规范项目也可以成为TCK和兼容实现的家。 如前所述，将兼容的实现分开保持是一种最佳实践（将实现与规范耦合甚至可能是一种不好的实践）。

项目管理委员会 ：顶级项目由项目管理委员会（PMC）管理。 一个PMC具有一个或多个PMC线索和零个或多个PMC成员。 PMC共同为属于其顶级项目的项目提供监督和总体领导。

在Eclipse Development Process （EDP）下，开源项目是按层次组织的。 特殊项目类型，即顶级项目，位于层次结构的顶部。 每个顶级项目都包含一个或多个项目（有时称为“子项目”）。 通常，顶级项目主要是组织结构，所有实际工作都在子项目中进行。

每个顶级项目都有一个PMC，该PMC负责监督其权限范围内的项目，以确保它们均在EDP，EFSP和Eclipse Foundation的知识产权政策所定义的规则下运行。

规范委员会 ：工作组的一个委员会，负责管理其工作组范围内的技术的EFSP。

开源项目是开发人员在Eclipse Foundation上进行协作的方式。 工作组是公司合作的一种手段。 例如，雅加达EE工作组将公司聚集在一起，在市场营销，生态系统开发，治理以及（当然）开源软件和规范开发方面进行协作。 作为其治理活动的一部分，工作组必须建立规范委员会，以代表工作组定义和管理规范流程。

规范委员会负责确保规范团队保持在其定义的范围内，并总体上确保由规范项目创建的规范版本是可实施的，并能满足工作组的目的。

过程概述 ：EFSP通过添加一些额外的检查和平衡来扩展EDP。

开发周期中的每个迭代都从计划开始。 对于第一个迭代，项目提案用作计划，创建复审用作批准。

规格项目提案 ：规格项目以提案开始。

项目建议书描述了将要创建的规范项目。 提案列出了范围，并提供了项目描述以及该项目将要制定的规范。

Eclipse Foundation有一个Web表单，用于定义项目建议。 在起草提案时，作者和任何指定为项目负责人的人都可以编辑该文档。 列出为规范团队的初始成员的每个人（即提交者）都可以查看文档。 该提案开放供社区审查后，可以公开访问。

根据EDP，该提案必须开放至少两个星期，以供社区审查，以向社区和主要利益相关者提供反馈并改进提案。 该提案可以在社区审核期间进行修改。

在开放给社区审查时，EMO将调查并批准与该项目相关的商标，Eclipse Foundation代表项目团队和社区持有该商标。 在此期间，EMO还将努力获得其他例外的批准。 这包括不在顶级项目的预先批准的许可方案之外的规范项目许可方案。

一切就绪后（商标，必要时的许可批准，导师的识别以及至少两周的社区审核），EMO将安排一次创作审核。

创作审核至少需要一周的时间。 EMO每月安排两个审查期。 评论归为一组； 根据结束日期进行安排，结束日期在每个月的第一个和第三个星期三。

该提案在创建审核期间被锁定，无法进行任何更改。 创作审查期是社区和利益相关者提供反馈的最后机会。 规范委员会和Eclipse Foundation的一般会员可以干预创建过程。 如果发现原因，成员可以要求EMO通过创建审核，并要求提案作者进行其他更改并重新启动审核过程，或者完全撤消提案（就其价值而言，这从未发生过）。

成功完成创建审查后，Eclipse Foundation将参与预配置过程，以将提案转变为实时规范项目。 设置从提交者的授权开始，该授权通过电子邮件请求发给提案中列出的所有提交者以参与我们的文书工作流程。 直到Eclipse Foundation的记录团队从至少一位提交者那里获得必要的书面文件之前，供应过程一直处于暂停状态。

提案文档用作第一次开发迭代的计划。 整个过程中的后续迭代依赖于发布计划的制定和计划审查。

发布计划 ：项目团队为每个发布周期制定计划。

同样，请注意，提案和创建审核将作为第一版的计划和计划审核。

该计划必须在范围内（即，所有新工作都必须在规范项目的范围所定义的范围内），并且必须考虑到利益相关者的关注而制定。 例如，它必须考虑PMC或相关工作组的总体计划。 值得注意的是，在制定总体计划时还必须考虑项目团队的关注。 我们谁都跑不了。

该计划通过计划评审传送到规格委员会。 规范委员会必须投票批准：要获得成功，必须获得三分之二以上的赞成票。 规格委员会的各个成员决定投票的方式各不相同； 但是，至少，成员们通过投票赞成，肯定他们相信计划的工作符合项目的范围，并且已经与社区和利益相关者进行了充分的磋商。

所有审核，包括计划审核，至少要运行一周。 他们从交付审核材料开始，到投票期结束。 对于计划审查，材料包括计划本身以及计划的简要说明（执行摘要）。 对于进度和发布审核（将在稍后讨论），审核材料包括项目内容的里程碑或发布候选版本。

所有评论均公开运行。 除了所需的批准外，审阅还为社区和采用者提供了一个表达其担忧的机会。 由于整个过程都是公开进行的，因此应将评审视为表达关注的最后机会：对规范过程有兴趣或兴趣的各方应尽早并通常通过特定于项目的公开渠道进行参与。

如果审核失败，则项目团队必须重新组合，合并反馈并重新参与新的审核。 EFSP对重新接合的时间没有要求。

提交者制定规范 ：提交者有权力和责任将内容推送到规范项目的Git存储库中。 在此过程中，提交方拥有大部分权力和责任。

必须正确使用发射器电源。 提交者具有强大的力量，但他们也承担着巨大的责任，并有望为社区和生态系统带来利益。

提交者接受贡献 ：提交者接受非提交者的贡献。 在GitHub世界中，采取提交者审查和接受请求请求的形式。

提交者有责任确保接受的内容在范围和发布计划之内，并遵守Eclipse Foundation的知识产权政策，并遵守IP尽职调查流程 。

参与者必须签署Eclipse参与者协议 （ECA）。

技术兼容性套件（TCK） ：在规范项目提交者开发规范资源时，TCK项目提交者和贡献者将组装TCK。

EFSP对TCK的住处没有任何要求。 它可以是相应规范项目的一部分，也可以是单独的。

分开时，TCK项目是传统的Eclipse开源软件项目。 提交者和贡献者在Eclipse开源软件项目上的工作方式与在规范项目中所做的几乎相同：提交者可以直接推送到该项目的Git存储库，并且必须检查并接受非提交者的贡献。

生成里程碑构建 ：项目团队将生成里程碑构建。

里程碑版本是规范版本（“规范版本”）的预发布版本。 里程碑版本仅供有限的受众使用（通常是项目团队本身，致力于候选兼容实现的提交者以及其他早期采用者）。

尽管可能不完整，但应尽一切努力确保里程碑构建在技术上是正确的。 兼容的实现不能基于规范的里程碑构建。

以后的版本可能会被标记为“候选发布”。 就EFSP和EDP而言，术语“候选发布”和“里程碑”仅在意图上有所不同。

进度审查 ：规范项目团队必须在其发布周期中至少进行一次进度审查。

进度审查是从EDP继承的概念。 进度审查的目的是确保工作在范围内； 一个项目正在朝着将被批准的发布方面取得进展； 并且遵守了EDP，EFSP和Eclipse Foundation知识产权政策。

在进行审查之前，必须将项目的知识产权贡献记录（ IP日志 ）提交给EMO进行审查和批准。 必须在一周（最短）的审核期开始之前提交审核的辅助材料，包括迄今为止取得的进展的简要说明（执行摘要）和项目内容的里程碑版本。 必须通过PMC代表的简单+1批准，并通过规范委员会的三分之二多数赞成，才能批准进度审核。

实施规范 ：规范项目的提交者在规范内容上工作时，其他团队可以在实施规范上工作。

在批准规范的特定版本并将其声明为最终规范之前（并且，当然，满足与最终规范相关的TCK的所有要求），该实现不能称为兼容实现。

EFSP对时序没有要求。 在代码优先的世界中，实现可能存在于规范之前。 在这种假设的情况下，实施项目的团队将根据进行中的工作来完善其实施。 预计实施团队将定期（通过公开渠道）与规范项目团队进行互动，以提供反馈和提出问题。

为了声明为最终的，规范需要具有至少一个兼容的实现，该实现实现规范的所有方面（包括任何可选部分），并根据EFSP中列出的一种开源许可（在下文中有更多说明）发布。

这就引入了一个“鸡和蛋”的问题：没有兼容的实现，我们就没有最终的规范，没有最终的规范，我们就没有兼容的实现。 规范项目，TCK项目和实现团队需要共同努力，以便至少有一个实现可以及时完成，以便在最终规范批准时正式发布并声明兼容的实现。

发布审核 ：规范项目团队必须在发布周期结束时进行发布审核。

必须根据EFSP指定的一种开源许可证分发至少一种兼容的实现：EPL-2.0，EDL-1.0（BSD-3-Clause），Apache-2.0。

根据进度审查的要求，在进行发布审查之前，必须将项目的知识产权贡献记录（ IP Log ）提交给EMO进行审查和批准，审查必须由PMC代表以简单的+1批准，并由规范委员会以三分之二的超多数票通过。

发行成功后，规范版本会迁移为最终规范。

最终规范 ：成功完成发行复审，包括以超多数票通过了规范委员会的批准，规范版本即被视为已批准，并且相关的工件由规范委员会推广和分发为最终规范。

批准的最终规范所引用的所有规范版本都必须自己批准。 相关规范版本的发行复审可以同时运行。

最终规格许可证 ：最终规格及其相关工件在特定许可证下分发。

最终规范的规范文档必须根据Eclipse Foundation规范许可以只读文本的形式分发 。 经过批准的复合材料TCK在Eclipse Foundation TCK许可下分发 。 其他技术工件必须在开源许可证（通常是规范项目的许可证）下分发。

兼容的实现 ：实现只能声称与最终规范兼容。

如前所述，在可以将其批准为最终规范之前，必须在指定的开源许可证之一下至少存在一个规范版本的兼容实现。 可以从最终规范中创建其他兼容的实现，并根据其他许可条款（由相应的供应商确定）进行分发。

从最终规范构建兼容的实现流程所需的知识产权。 也就是说，为了被视为兼容的实现并从Eclipse Foundation Specification Agreement提供的知识产权保护中受益，实现必须基于最终规范。 对于实现里程碑构建或未批准的规范版本，不得声明任何兼容性。

翻译自: https://www.javacodegeeks.com/2019/03/eclipse-foundation-specification-process.html