本文档中的材料按概括到详细的顺序组织。如果您要概括了解 OpenSolaris 及其开发过程，只需阅读开头的介绍性材料即可。后续部分概括性地逐步介绍了该过程，并提供了附录，其中包含与相应过程中特定步骤相关的更深入的详细信息。 OpenSolaris Developer's Guide 中具体介绍了详细步骤和相关工具。在所有情况下，都是从实现者的角度介绍这些过程，但同时也介绍了以其他角色身份进行操作的人员的职责。

词汇表中提供了常用术语的定义。在整个软件工程业以及各种开放源代码的团体中，这些术语的使用存在许多不一致甚至冲突。这些定义旨在确保在本文档其余部分保持一致。

第一章 “基本知识”介绍了相关背景信息，并解释了采用严格的系统化开发过程的缘由。然后，从较高的层次介绍了 OpenSolaris 共同开发工作的范围和目的，以及 Solaris 操作系统与该工作之间的关系。最后，我们提供了一组较高级别的技术设计和过程标准，这是多年来在 OpenSolaris 代码库中建立的标准。设计与实现符合这些原则的软件是 OpenSolaris 开发的主要目的。

介绍了相关背景信息之后，又介绍了管理 OpenSolaris 代码库所涉及的过程。 “发行管理”一章介绍了发行版命名和编号以及更改管理规则。另外，还介绍了分支管理策略和发行标准。此讨论与任何特定的源代码管理制度无关。< /p>

第三章 “开发过程”从实现者的角度介绍了该过程的流程，并详细地进行了阐述。此过程非常接近当前在 Sun 的 Solaris 组织内实现的软件开发框架 (Software Development Framework, SDF)，它经过了修改以采纳个人和团队（他们彼此之间没有进行连续、直接的交流）工作的成果。因此，它适于地理位置和组织上都分散的开发。另外，还提供了针对其中各部分实现的测试和质量保证方面的详细信息。

附录提供了有关开发过程中每个步骤的详细信息，在本文档的其余部分中多处引用了这些附录。

基本知识

本章概括介绍了何谓 OpenSolaris 以及它与来自 Sun Microsystems, Inc 的 Solaris 产品的关系，并介绍了一些设计原则，以供希望向 OpenSolaris 整合的发行版分支提供更改反馈的参与者使用。最后，本章还介绍了一组在对开发过程自身进行更改时要应用的原则。

OpenSolaris 计划

什么是 OpenSolaris 计划？

OpenSolaris 计划是一个开放源代码项目，它最初是在 Solaris 操作系统的源代码的基础上展开的。它是团体开发工作的纽带，来自 Sun 和其他任何地方的参与者可以合作开发与改进操作系统技术。OpenSolaris 源代码的用途很多，包括作为未来版本的 Solaris OS 产品、其他操作系统项目、第三方产品以及团体感兴趣的分发的基础。当前，OpenSolaris 计划由 Sun Microsystems, Inc 发起。

在最初的阶段，OpenSolaris 计划将提供当前随 Solaris OS 分发的核心内核、库及命令。以后，在该项目中还会提供 Solaris OS 的其他部分。

OpenSolaris 计划与 Solaris 操作系统有何不同？

OpenSolaris 计划并不提供最终用户产品或完整分发，而是提供开放源代码库、使用代码进行开发所需的生成工具以及交流与共享相关信息的基础结构。对代码的任何支持均由相应团体提供，Sun 不会以源代码形式也不会以二进制形式为 OpenSolaris 产品提供任何正式支持。

Solaris OS 是 Sun 的操作系统分发产品，Sun 将其作为 Sun 产品进行推广、维护和支持。未来的 Solaris 操作系统发行版将采用 OpenSolaris 源代码生成，但支持方式仍与当前的 Solaris OS 版本相同。在任何特定时间，OpenSolaris 计划或 Solaris OS 产品中都可能存在对方没有包含的一些软件。但我们希望以后通过 OpenSolaris 计划不断地发布尽可能多的现有源代码，并希望将来在 OpenSolaris 团体中进行开发。

设计原则

多年来，在开发构成 OpenSolaris 的基础的源代码中一直恪守一组设计原则和核心价值，目的是为用户提供一个用以开发和运行应用程序的丰富、连贯且稳定的平台。此平台的属性以及平台中采用的技术就是应用这些设计原则的成果。

软件本身固有的特征是，随着时间的推移不断发展，并且几乎总有改进的潜能。实际上，现今 OpenSolaris 的某些部分还尚未完全体现这些原则。但是，这些原则对 OpenSolaris 的特性而言是必不可少的，参与者需要谨记这些原则，即使是进行非常小的改动也是如此。

当然，这些原则并不是 OpenSolaris 独有的。但它们确实是一流软件设计的基础。软件的可用程度体现在与操作系统的其余部分配合的程度，以及满足用户对相应操作系统的期望的程度。例如，某个快速开发出的新功能软件，如果未考虑如何维护，那么该软件很可能不会发展，且最终会被弃用。又如，某个新功能软件独立来看很新颖，但却无法进行观察或调试。此类软件的维护负担较重，这不仅是对原开发者而言，对所有其他参与者或某个时刻涉及的用户也是如此。

可靠性

无论是在单处理器的膝上型计算机中运行，还是在巨型机类、多处理器系统中运行，最重要的是操作系统都必须是可靠的。这意味着 OpenSolaris 必须正常运行，从而确保结果准确，数据不会丢失或损坏。如果无法正常运行，必须有一个适用的基础结构能够在第一次出现故障时即确定故障的根本原因。这样不仅可以解决软件中的问题，而且还可以避免第一个故障引发其他故障。

可用性

OpenSolaris 必须最大限度地提供高度可用的系统，而不会影响其可靠性。同样，操作系统在处理软件故障（如果可能的话，还有硬件故障）方面必须足够强健。必须将服务设计为能够在出现了应用程序故障时重新启动，且 OpenSolaris 本身必须能够在出现了非致命硬件故障时恢复。如有可能，OpenSolaris 不得要求通过重新引导来使新服务联机、使服务脱机或者修复软件或硬件组件。

可维修性

由于在软件栈的每个级别以及各种硬件级别都可能存在问题，因此操作系统应具备诊断问题的功能，这一点是不可缺少的。新功能必须提供观察正常运行的系统和事后故障转储中情况的方法，最好是利用现有的观察机制。OpenSolaris 不得要求在其他位置重现问题或要求被检测的软件诊断问题，而应能够在生产环境中诊断任意问题。它必须能够诊断致命问题和瞬态问题，并且如有可能，能够自动执行诊断。如果无法自动执行诊断，则必须清楚记录要使用的方法，以便其他人可以确定问题的根源。

安全性

在日益危险的计算世界中，必须在操作系统设计中考虑 OpenSolaris 安全性，密切关注每个组件和子系统。操作系统必须安全、开包即用，且具备适用机制，以便审核对系统进行的更改以及何人执行更改。如果出现安全漏洞，OpenSolaris 必须设计为能够尽可能地将泄漏降到最低程度。

性能

虽然让操作系统的运行达到完全准确是不可能的，但提高速度却是可以实现的。也就是说，与相同环境中运行的其他操作系统相比，OpenSolaris 的性能必须首屈一指。承担的负载增加时，操作系统的性能不得降低，而且它必须与系统的可用硬件资源相协调。OpenSolaris 必须允许一定的延迟时间，以支持实时应用程序。

可管理性

随着操作系统以及其中运行的硬件越来越复杂，有效管理问题突显出来。OpenSolaris 必须提供强大的提取功能，以简化系统的管理，而不会增加复杂性。它必须允许能以一致、简单的方式管理各个组件、软件或硬件。

兼容性

在软件栈的每个级别，都必须将提供长期兼容性视为强制性约束，而不仅仅是目标。OpenSolaris 接口设计必须使用记录的约定级别，而且对这些接口所做更改必须符合约定的兼容性。新的子系统和接口必须可扩展并确定版本，以便将来进行增强和更改时不会牺牲兼容性。如果接口的兼容性发生变化（包括删除接口的情况），必须就此更改与团体进行正式沟通。

可维护性

软件并不是静态算法（不随时间推移发生变化）的集合，而是随着新需要和要求的出现不断发展。OpenSolaris 的框架必须设计为可在以后持续维护，特别是可由大型开发团体维护。必须为 OpenSolaris 建立合适的体系结构，以便将常用的子例程组合到任意数量的用户都可以使用的库或内核模块中。必须为 OpenSolaris 做好记录，方法是在源代码及其他位置（如设计文档）中有效使用注释。

平台中立性

OpenSolaris 是使用单一源代码库构建而成，因此，几乎在所有情况下，在所有平台之间，功能和特性都是相同的。OpenSolaris 必须继续保持平台中立性，而且必须设计较低级别的提取功能，同时要将多种平台以及将来会出现的新平台考虑在内。

过程原则

参与 OpenSolaris 不只需要了解该计划的设计原则，还有一些适用的开发过程，用于引导、促进以及最终强制将来的开发遵从规定的设计原则。该计划的参与者必须了解这些开发过程。

这些开发过程本身在最初产生时就考虑到了许多价值理念，其中包括能够从涉及多个不同层和子系统的项目缩小到解决涉及范围很小的缺陷的简单修复程序。其中每种价值理念或过程原则都旨在指导创建新过程，以持续发展 OpenSolaris、尽可能高效地开发并确保具有最高质量为首要目标。

开放

很显然，由于众多参与者使用、学习并最终有机会更改 OpenSolaris， OpenSolaris 从中受益匪浅。因此，必须在开放的环境中开发 OpenSolaris ，其中采用的是透明且允许所有级别的参与活动的过程。

根据情况缩减

虽然整体而言 OpenSolaris 开发过程中的每个步骤都有重要作用，但某些步骤可能不适用于某些类型的建议更改，或者某个步骤的范围过大。因此，必须采用以下方式设计过程：在不影响或降低整合的发行版分支质量的前提下，可以在不需要完整的步骤时，减少、优化甚至取消完成相应步骤所需的时间和材料。

公平

必须合理制订开发过程，以便在团体的所有参与者部分间公正地管理该过程。有关过程中某个特定步骤的范围的变化情况以及要求参与者提供的内容不得基于参与者，而应基于参与的内容。

意图明确

OpenSolaris 开发过程中的每个步骤都是用来解决对整合进行更改的非常明确的实际需求。因此，开发过程中的步骤时，必须谨记明确的意图。不得任意添加或更改过程中的步骤，而是必须根据获得的实际数据（这些数据经过了分析以确定通过当前过程能够将特定问题解决到什么程度）来判断过程中的步骤是否可以调整。

策略

所有 OpenSolaris 整合都必须符合以下策略，除非董事会或其指定代表已准予特定例外情况，并在会议备忘录或批准的快速跟踪中记录这一情况。其中每个策略都针对许多股东的位置进行了限定，使其对每个技术领域中的项目团队和整合的要求降到最低限度。出于对参与者的利益的考虑，需要整合（无论是单独还是共同）更为详细地重申这些策略。

对于外部代码库（如第三方生成的开放源代码软件），整合可以选择放宽某些策略。例如，ON 整合不会期望集成的开放源代码软件能满足国际化策略要求。

可访问性

所有 OpenSolaris 软件都应符合美国政府 Section 508 中的可访问性要求。

体系结构审查委员会 (Architecture Review Committee, ARC)

集成到 OpenSolaris 中的所有软件都应符合 OpenSolaris 接口分类法。

体系结构中立性

所有通用（即与硬件无关）代码都应在所有受支持的 OpenSolaris 目标平台上经过测试并运行。在集成之前，必须确保代码可以正常运行，且具有达到目的所需资源。

功能终止 (End of Feature, EOF)

可以从 OpenSolaris 次发行版中删除用户可见的功能，但条件是：(1) 在实际删除之前，董事会（或其指定代表）和 ARC 批准公开通知一段特定时间，(2) 董事会（或其指定代表）和 ARC 批准实际删除。用户可见功能的约定级别通常为不稳定或更高。仅特定组可见的功能（例如，按合同提供的功能或合作伙伴专用的功能）在经 ARC 批准后可以删除，时间长度可由特定组决定。

国际化 (I18N)/本地化 (L10N)

所有 OpenSolaris 软件都将国际化，这意味着软件需要支持一些接口，以允许将消息、数字和日期格式以及类似的数据表示形式替换为符合用户语言环境的对应内容。欢迎提供本地化数据表示形式，但不应由原始代码参与者将其提供给整合。

IPv6

所有支持 IPv4 的 OpenSolaris 软件也都支持 IPv6，或有已约定且能够实现的计划，从而能在一定的时间后支持 IPv6。

整合错误策略

参与者在通过整合的发行版分支发布更改之前，应该解决新功能中的所有错误。通常由整合来做出决议。例如，整合可能会声明，不会集成未修复高优先级错误的任何项目。但管理整合的团队可以代表董事会准予一些例外情况。此类例外情况应记录下来，以便整合可以确定先例，并能够预测情况。

为共同完成的软件颁发许可证

所有共同完成的软件都必须可以随意修改和重新分发，并根据共同开发和分发许可 (Common Development and Distribution License, CDDL) 的许可或支持 CDDL 的许可颁发许可证。

发行管理

发行类型

OpenSolaris 的兼容性核心价值和专门用于实现该目标的过程可能看起来让人却步，并会阻碍创新。本节旨在深入介绍这些过程以及可在其中完成的事项，并为希望了解详细信息的人员提供查找参考文档的资源。

首先应该注意，与 Solaris 2.0 相比，Solaris 10 是一个截然不同的庞然大物。在过渡阶段中出现的所有创新都在如今仍适用的相同兼容性约束下实现了。

实际上，这些兼容性约束可以促进创新，而非阻碍创新。这称为“约束的自由”。如果您的项目所依赖的接口受到约束，那么您就可以集中精力开发项目，而不必不断使其适应变化的环境。

要了解专门用来推动兼容性的过程并采用其展开工作，需要了解一些基本概念。

在整个行业中，通常将产品发行版分类为主发行版、次发行版或微发行版，并采用我们都熟悉的“点”符号表示法来体现这一点。而且在整个行业中，这些术语暗含的意义是人们对某个发行版是小型、中型还是大型所作出的价值判断。那就是市场覆盖状况。

在 Solaris 以及现在的 OpenSolaris 中，对于在特定类型的发行版中哪些接口可以进行不兼容更改，有一些附加约束。在主发行版中，任何接口都可以进行不兼容更改。在次发行版中，大多数接口都不能进行不兼容更改；在微发行版中，可以进行不兼容更改的接口就更少了。通过为每个接口指定接口分类法（参考）级别，可以清楚区分各接口。后面介绍了有关接口分类法级别的更多信息。

请注意，在第二段中，引用了 "Solaris 2.0" 和 "Solaris 10"。如果采用常见的 Major.Minor 符号表示法，"Solaris 10" 实际上是 "Solaris 2.10"。但是，由于 Sun 决定在可预见的将来不会创建其他的 Solaris 主发行版，因此省略 "2"。另请注意，执行 "uname -r" 的输出为 SunOS 组件（整合）的完整 Major.Minor[.Micro] 发行编号。取消顶级的 "2" 反映了坚守兼容性核心价值的约定，并且预期 OpenSolaris 仍会坚守这一约定。Solaris 和 OpenSolaris 的次发行版的含义为“大型、酷且可兼容”。

这就切入到了接口稳定性和接口分类法的主题。 接口分类法文档正在修改过程中。目的是为了将其简化，一部分是为了满足在开放环境中工作的需求。虽然目前该文档还没有最终形式，但已知一些实质的更改，下面的概述就反映了这些更改。

接口分类法将接口分为两大类：公共和专用。公共接口可供所有人使用，而专用接口仅供一部分可能的用户使用。公共接口和专用接口都有若干子类。对于公共接口而言，这些子类反映的是在哪些类型的发行版中，接口可以进行不兼容的更改。对于专用接口而言，子类反映的是受支持用户的域。

务必强调的是，专用并不意味着保密，反之，可见也不意味着公共。实际上，只需检查头文件便可轻松发现许多专用接口。

下面是相关的（新）公共分类法级别：

稳定：只有主发行版中，接口才可以进行不兼容的更改。专门供 ISV 和系统集成者使用的接口要求此级别的支持可用于这些用户。

未约定：只有主发行版或次发行版中，才可以进行不兼容的更改。这适用于某些系统管理工具和未测试的新接口。

可变：可在任何发行版中更改。仅当接口定义由 OpenSolaris 团体之外的主体控制，并且认为跟踪团体比接口兼容性更重要时，此级别才有用。

不是接口：只是一个简便术语，用来将看似受支持的接口标记为不受支持。这是缺省分类，此术语仅在可能存在混淆时才明确应用。

用于公共分类法级别的准确术语还尚在讨论中，这属于接口分类法文档更新的一部分。

请注意，能够在特定发行版中进行不兼容的更改并不表示必须进行这种更改。例如，OpenSolaris 团体之外的其他人控制的大部分接口当前都归为“可变”类别，但与这些团体引入的主要不兼容性进行同步通常会延迟到次发行版可用时。

有时也可以不必遵循这些规则，但需要提出非常有说服力的理由。以下三个理由通常可行：

支持的标准（具有品牌影响力）已进行了重新解释，现有的实现不再符合。
接口定义本身存在安全漏洞。
接口定义本身存在数据损坏。

根据个别情况，也可以接受其他理由。例如，由于 Microsoft 放弃了 8.3 DOS 约定，我们就不再遵循 "pcfs" 中的兼容性（与大小写有关）。否则，我们会遭人嗤笑。

应该注意到，OpenSolaris（特别是核心的 ON/SunOS 整合）很少使用“未约定”分类法级别；该级别主要由兼容性约束较少的市场中的其他 Sun 产品使用。但出于以下两个原因，该级别的使用将会增加：

－那些“其他 Sun 产品”会逐渐成为 OpenSolaris 的一部分。（这不会影响核心的 ON/SunOS 整合。）

－当前分类为“可变”的接口要提升为“未约定”。随着这些接口的使用日益增加，微发行版之间的兼容性现在已胜过追随快速前进的外部团体。（这会影响核心的 ON/SunOS 整合。）

下面是相关的专用分类法级别：

项目专用：只能由提供接口的项目使用。这是专用接口的缺省级别，不需要正式检查。但如果打算以后提高其可用性，那么检查会很有用。（ OpenSolaris 可能会将项目视为与团体大致相当。）

整合专用：只能在提供接口的项目所属的整合中使用。

OpenSolaris 专用：（Sun 内部使用，称为 Sun 专用私有。）可由 OpenSolaris 的任何组件使用。应该注意到，这通常是由于进行了不兼容的更改而需要协作时，不得已采用的做法。

这会对 OpenSolaris 开发人员产生什么影响？

正面影响是，可以针对能使用哪些接口（或即使是在允许使用那些接口时）做出明智的决定。这样您便可以在极大程度上控制其他项目对您的项目的影响。即使短期内看起来会造成不便，但随着时间的推移，其好处会呈现出来。

负面影响是，在为了维护兼容性而修改项目提供的接口时，可能不得不经过几次跳跃。例如，UNIX 中一组典型的例程 "wait"/"wait3"/"wait4"/"waitpid"/...；随着所需语义的发展，较旧的例程无法继续发展来满足要求，因此开发了新例程，同时保持旧例程可用、兼容及受支持。应注意，这种非常特殊的示例极为少见。较常见的情况是，发展接口所采用的方式稍微不如完全从头开始时那样顺畅。注意上句中“稍微” 一词体现出的差别。

分支管理

OpenSolaris 管理策略假定存在多个同时进行的开发组。某个特定的开发组与某些代码库关联，通常但并不总是整合。不同的整合可能有相关的多个开发组，但不需要同时完成它们的发行版。这些假设成立的条件是存在现有的 Solaris 开发模型以及许多开放源代码开发工作。

用于描述并行开发的术语通常依赖于使用的特定源代码控制模型；但是，基本的工作流程大致类似。为避免混淆，请参见词汇表了解术语定义。

在整合使其当前发行版成为最终发行版（交付相应发行版的最终正式快照）之前，主干将划分为两个发行版分支：主干（通过它为下一个发行版集成开发）和当前发行版的分支（通过它完成当前发行版并使其成为最终发行版）。划分时，对于源代码库中的任何版本信息，将在主干中进行修改以反映下一个发行版，而在以前的发行版分支中保持不变。发行团队与确定了版本的发行版关联，也就是说，这一步可视为由新的发行团队创建新的主干。现有的发行团队一直负责以前的发行版分支，直到它成为最终发行版。

所有的发行版分支都要遵守本文档后面概述的质量标准。此外，发行团队不会提供随机选择的任意快照。尽管分发可以使用这些快照，但只有发行版中的最终快照才视为整合内容的正式发布。通常，由于人为的失误，任何未完成的发行版分支中都会存在一些缺陷，在正式发行版不应存在这些缺陷。因此，在对发行版进行定稿处理时，需要降低更改率，以便找出那些缺陷。

在任何分支中，为了管理风险，发行团队有责任和权利要求仅在项目已做好集成准备并且分支已做好接收项目准备的情况下才集成项目。这可能意味着，在发行版中后期集成项目的工作可能会推迟到下一个发行版开始时。< /p>

在开发周期中具体何时“划分”关系到平衡冲突事项；如果在接近新发行版开始时划分，则会增加两个次发行版分支处于活动开发的时间，这会分割资源并需要较多合并操作。如果在接近发行版完成时划分，通常意味着要在完成前一个发行版完成之后，才能开始下一个发行版，从而增加了项目集成的延迟。

活动分支和对等发行版。

包含所有正式组成 OpenSolaris 的整合的主干通常总是遵循次发行版绑定规则，并受各自发行团队的控制。

划分后，待完成发行版分支继续遵循次发行版绑定规则，直至完成相应发行版，但应减少集成次数。如果有新的开发，应在下一个发行版中进行，待完成发行版的发行团队可以出于风险管理的考虑拒绝集成。

也可以从最终发行版创建分支，然后将其开放以继续开发。如果这样，生成的发行版为更新发行版。每个更新发行版都有自己的发行团队，并遵循微发行版绑定规则。尽管每个更新发行版团队都可建立自己的集成标准，但通常情况下，针对更新发行版的所有更改都必须先集成到主干中，并且必须向后移植（而非合并）到更新发行版分支中。其中每个步骤都需要进行独立测试。在主干中，大多数更新发行版团队都需要有一段“吸收时间”，所需的确切吸收时间可能取决于更改的类型或范围。发行团队总是有权强制实施它认为合适的任何附加要求。

请注意，通常情况下，为集成到主干的更改生成的大部分材料都可在集成到更新的过程中重用。更新集成过程的主要事项是确保更改适于更新发行版。

发行版绑定

发行团队可为其分支定义针对更改的适用发行版绑定。对更新发行版分支而言，这通常为微发行版绑定；对所有其他发行版分支而言，这通常为次发行版绑定。项目分支通常与其针对的发行版分支遵循相同的发行版绑定规则；不以集成为目标的项目团队可让其分支应用所需的任何发行版绑定。

正如发行版的定义所表明的那样，兼容性规则并不应用于发行版内部，而是仅应用于已完成的发行版与其已完成的父发行版之间。但这些规则并不应用于发行版的快照之间。但需要注意的是，有些缺陷通过不兼容的更改可以非常容易地修复。如果将一个新接口集成到发行版分支中，然后将其向后移植到另一个发行版分支中，之后发现了这种类型的缺陷，如果要在其中任何一个发行版分支完成之前，对两个分支进行相同的不兼容更改，那么就需要进行大量的协调工作。

质量标准

OpenSolaris 预计会包含许多开放源代码项目，这些项目的执行采用的是 OpenSolaris 管理模型。预计每个项目在其各自的规章内都有一定的自由度，这些规章定义项目的执行方式，包括质量评估和缺陷管理等方面。但是，当 OpenSolaris 中的项目希望通过整合的发行版分支（包括主干）发布更改时，所建议更改的质量必须符合特定的质量标准。

倒退执行标准

倒退是在适当或通常是适当的、记录或预期的行为中出现的非计划变化。一种类型的倒退是操作系统的行为不太符合其记录和规定的规范。这些倒退可能像出现新的伪错误消息那样微不足道，也可能像操作系统出现灾难性故障那样严重。对发行版分支不做更改会导致该分支从其当前状态发生功能倒退。此类倒退会造成基于 OpenSolaris 的所有项目都要花时间来跟踪工作中的潜在问题，这样，就浪费了团体中很大一部分的时间，而这部分团体并不仅限于引入这种倒退的参与者。这反过来还会减缓将来开发的进度。在大多数情况下，在执行所建议更改之前，通过执行全面且严格的测试计划可以防止出现功能倒退。& amp; lt; /p>

另一种类型的倒退发生在通过一个或多个宏和/或宏基准测试程序测得的系统性能上。必须尽一切可能避免此类倒退，通过采用防止功能倒退的相同测试方法，可以防止此类倒退。由于每个发行版分支都有一套与之相关的性能标准（该标准将是适用于相应发行版的大型质量标准的组成部分），因此，根据特定分支的标准以及与这些标准相关的发行版的当前状态，发行团队可以允许存在所建议更改引起的性能倒退。

完整性执行标准

即使新引入发行版分支中的更改不会引起倒退，也必须满足更改应达到其预期目标这一基本要求。新功能必须满足项目团队提出的关键要求。这可以通过执行严格的测试计划（已经过检查，表明其是全面且完整的）来确定。对于无法表明是否满足了关键要求的项目，将不允许它们通过整合的发行版分支来发布其更改。

此外，只要对发行版分支进行任何类型的更改，就需要对现有的倒退测试套件进行对应的更改。当添加了新功能以便可以测试将来的更改（很可能不是由原始项目做出）并表明不会降低 OpenSolaris 的质量时，尤其如此。即使是在修复现有缺陷的情况下，添加其他测试套件或为现有套件添加评判标准，通常也是很有用的，并且有时也是必需的。关键是提供所有 OpenSolaris 参与者都可以使用的强大测试套件，以便最大限度地确保所建议更改功能完整并且不会引起倒退。

摘要

对于 OpenSolaris 质量要求，最好的表述就是“随时做好生产准备”。意思是在任何时候，整合的发行版分支都必须达到足够高的质量，以便可以原样用作分发或产品的基础。通过执行严格的质量标准，团体可以强制 OpenSolaris 尽量避免质量停滞不前。当参与者和用户同样都听说了分支已破坏，因此他们不再将最新的更改整合到自己的项目范围中，甚至停止使用分支本身时，会出现上述情况。这会导致实际测试减少，因此无法发现更多的错误，分支的质量会进一步下降。当出现质量停滞不前时，很难扭转，并且恢复的时间会很长。

开发过程

开发过程的流程很大，无法用一个流程图表示出来，因此将其分为四个阶段：创意、设计、实现和集成。如前所述，OpenSolaris 的一个过程开发标准是“根据情况缩减”，这是指过程中的各个步骤只是根据需要来应用，不需要时可以跳过。另请注意，开发人员可以“向前跳”以及不按顺序执行步骤，但这会显著增加重复工作的风险。最后，在决定哪些是需要的以及哪些是不需要的时，做出好的判断极为重要。

请注意下面图中的颜色，它们用来指示范围：

－浅灰框适用于所有更改。－中蓝色框适用于大中型更改。－亮蓝色框仅适用于大型更改。

创意

首先，有人提出了某个增强功能的创意或发现了某个缺陷。第一步是确定是否已记录错误/RFE，如果没有，就将其记录下来。下一步是在某处公开错误/RFE 以便就其展开讨论，这应该有助于确定所建议更改的复杂性，估计团体的兴趣以及找到可能的团队成员。在此，开发人员可以确定他们是否有前进所需的支持。如果更改集相当大，就可能需要组建团队，制定项目以及找到设计审查人员。一旦成功完成了上述所有事项，便可进入设计阶段。

设计

在设计阶段，要同时进行若干项工作。首先是确定是否确实需要正式的设计审查，对于小型的 RFE 和错误修复，答案通常为否，而对于大中型的 RFE 和项目，答案通常为是，但对于过程的大部分而言，这是一个判断要求。如果需要正式审查，就需要确定审查人员，创建要审查的设计等，另外，如果需要，还应进行体系结构审查。如果牵涉到一些利害关系，则需要说服相应的股东这样做是合适的。另外，还必须创建并批准测试计划（无论是非常小的测试计划，还是复杂的测试计划）。如果需要，应该制定一个详细介绍资源的计划表。

实现

在实现阶段，也要同时进行若干项工作。其中第一件且通常是最重要的工作是编写实际代码，同时确保代码符合适用的策略，并通过各种单元和预集成测试。此外，还要编写文档和测试套件。在为集成阶段做准备的过程中，还应确定代码审查人员。

集成

集成阶段是确保计划完成的每项工作都已实际完成，这意味着要进行许多审查，包括代码、文档和完整性。请注意，“审查完整性”步骤由 最终审批者来执行；在 Solaris 模型中，这些审批者是 C 团队 和/或 CRT，但在 OpenSolaris 模型中并未明确指定他们是谁，尽管他们将会以与其整合同等的角色执行操作。一旦完成了所有审查并授予了集成权限，便可集成了。最后要根据需要传达更改：将带标题和/或标志日的消息传达给相应的团体，可能的话，向支持组织传达相关信息。

词汇表

应用程序二进制接口 (Application Binary Interface, ABI)

ABI 定义用于已编译程序的系统接口。这通常指定为带源代码到二进制代码转换规则的 API。

应用程序编程接口 (Application Programing Interface, API)

API 定义用于源代码级别的程序的系统接口。

分支

代码库中的开发组，根据其他分支（通常为主干）的快照创建而成。在各个单独的分支中，独立地进行开发，但可能会遵循分支的集成规则按任一方向进行合并。通常有两种类型的分支：发行版和项目。

C 团队

整合团队：管理特定整合的发行团队。

更改审查团队 (Change Review Team, CRT)

更改审查团队是特定整合团队特许设立的一组技术参与者，他们管理对所建议更改的技术风险和优点进行评估的日常业务。CRT 处理的典型评估是针对用于多组错误的修复程序的集成请求，项目集成通常由整合的发行团队管理。

命令行界面 (Command Line Interface, CLI)

CLI 定义基于命令行的实用程序的调用语法。

团体

团体是有一个或多个共同兴趣的一组人员（“成员”），大家在一个或多个已知的公共论坛中进行交流。团体不是要提供源系统信息库，而是需要关注与其感兴趣的领域相关的一个或多个正在进行的项目，也可以关注发布这些项目的整合。

整合

整合是以开放的方式工作的一个或多个人员参与的技术工作，整合的具体成果是将一个或多个项目生成的技术产物组合成一个连贯的集合，以便于组合到分发中。整合也可以包括对其自身的生成工作或其他工作的参与。整合具有一个或多个源系统信息库，这些库将相关项目的源产品和其他选定产物组合为连贯的整体。整合关注的重点是对分发有用的产物的发布机制。其次考虑是否对用户有用。整合成员（如项目）通常由参与者构成。

完成整合后，至少应该有源树、关联工具以及“原始区域”，后者是与源代码树的编译输出关联的文件系统内二进制代码交付产品。根据对利用整合的分发的期望，可以选择以软件包格式发布二进制代码。

参与者（个人）

参与者能够从事对项目或整合有用的工作。从事的工作包括创建或修改代码、分析故障、管理与项目相关的工具、创建体系结构或规范文档，甚至协调其他参与者的工作等等。某项工作是有用还是无用，具体由项目或整合来决定。交流的项目（如 Advocacy Project）可能会将个人在会议或其他实际会议中的积极表现视为贡献。

标签“核心参与者”与对项目或整合提供重要指导的参与者有关。核心参与者可能要参加所有投票以及就机制展开讨论。

分发

分发是可能以开放或封闭的方式工作的一个或多个人员参与的技术工作，分发的具体成果是将一个或多个整合生成的技术产物（和可选的一个或多个项目）组合为一个连贯的集合，该集合能够执行通常与给定类的应用程序相关的一组功能中一部分有针对性的功能。分发也可以包括参与其自身的生成，或来自其他来源的参与工作。分发关注的重点是面向用户的产物的发布机制。分发成员关系通常由参与者构成，虽然使用非开放过程的分发不需要任何实际的参与者参与其中。

完成生成软件产物的分发后，至少应该有可执行形式的该软件产物。

文档

对接口语法和语义所做的说明，以便人们可以读懂。其中可能包括手册页、信息文件、“指南”、自述文件及其他形式。头文件和源文件内容明确排除在外。

快速跟踪

用于审查团体提出的建议的快捷过程。适于进行此类审查的建议通常是那些显而易见且无争议的建议。快速跟踪审查通常在一段固定的时间内通过电子邮件进行。如果已到为建议安排的时间，而且没有提出重大异议，则自动批准相应建议。

标志日

标志日是指影响很大一部分使用整合的开发发行版（或当前版本）的参与者的代码集成。例如，修改生成工具通常需要从生成源代码树中删除现有对象文件，这视为标志日。标志日附带来自集成参与者或代表他们的 C 团队的澄清消息。该消息说明更改的各个方面以及在标志日继续工作所需的步骤。

接口

Merriam-Webster 对接口定义如下：

2 a：独立且通常不相关的系统相遇、执行交互式操作或通信的地方。 b：在接口处实现交互式操作或通信的方式。

在本文档的上下文中，接口仅是指一个软件对象在另一个软件对象中导出或导入的已记录语法和语义，其中可能包括（但不仅限于）：

库 ABI（暗含 API）。

实用程序 CLI。

文件格式

文件系统布局（包括文件位置）

接口的实现还有行为产物（如在特定条件下的性能），这些产物未指定，因此不是“接口”的一部分。实现的开发人员假定任何人都不会依赖这些未记录的功能，客户不应依赖这些产物（或使其成为规范的显式部分）。但接口的功能或其总性能特征可以视为接口语义的隐式部分。

接口分类法

一个文档，用于定义应用于接口约定级别的术语，并提供语义定义以及与那些级别和发行类型关联的规则。用户可以在手册页的“属性”区域中类型“接口稳定性”下看到这些约定级别。

成员（个人）

成员参与（可能只是观察）其所属团体主持的交流活动。

父/子分支

创建新分支时，用作初始内容来源的已存在的分支是父分支，新创建的分支是子分支。在创建完分支后的瞬间，父分支和子分支的内容完全相同。

产品

产品是分发的特定发布，至少可以通过发布时间进行区分。

项目

项目是以开放的方式工作的一个或多个人员参与的技术工作，项目的具体成果是生成少量协作的技术产物。一个项目有一个或多个源系统信息库，其中每个库都旨在通过某种方式进行发布。项目可以选择将其主要发布形式在一个或多个整合中实现，虽然这并不是必需的。项目至少可从一个方面区分积极参与项目的人员（参与者）和只对项目进度感兴趣的人员（成员）。

项目分支

项目团队用来协调工作的开发组。项目分支通常从整合的主干创建而成，从其父级接收定期合并，在项目完成后合并回其父级并停用。不打算在整合中发布的项目可能占用单独的代码库，而不是现有整合的分支。项目还可以在每个代码库中都有分支。

项目团队

项目的所有参与者。项目团队负责建立自己内部的管理和开发过程，并负责确定适合其项目分支或代码库的更改。

原始区域

分层文件系统，其中包含与特定源代码树的编译输出关联的二进制代码交付产品。例如，根目录为 "/path/foo" 的源代码树可能有一个proto目录/path/foo/proto，该目录下的所有内容都将称为原始区域，如果 "/usr/bin/x" 和 "/etc/x.conf" 都属于二进制代码交付产品的一部分，它们将分别在原始区域中的 "/path/foo/proto/usr/bin/x" 和 "/path/foo/proto/etc/x.conf"。

发行版分支

整合的代码库的分支，在其中对项目和/或错误修复进行集成以便发布。一个整合同时可有多个活动的发行版分支，每个分支雇用不同的发行团队，并执行不同的集成要求。

发行版

单个发行版分支的一个或一系列快照。对于各发行版，都可应用体系结构一致性要求。

稳定

OpenSolaris 中最常用的接口约定级别（请参见接口分类法）。只能在产品的主发行版中，对稳定接口进行不兼容的更改。

请注意，此用法与指开发树的稳定分支的常见团体用法不同。

Solaris 的 "attributes(5)" 手册页中提供了有关所有接口稳定性级别的信息。

主干

整合的最新发行版分支。主干是最新开始的发行版分支，也是在整合使用版本控制时版本号最高的分支。所有项目和所有适用的错误修复都在其他发行版分支之前集成到主干中。源代码管理系统中显示的主干的特定名称以及该名称是固定的还是随时间变化都是实现细节，这也是主干与其他分支之间在表示形式上的区别。

用户（个人）

使用一个或多个采用某种输出形式的分发、整合或项目，但不参与任何与这些工作相关的交流的个人。可将用户视为通过许多技术工作所生成的技术的纯使用者。

附录 A. 接口分类法

（一旦 PSARC/2005/220 完善且概念明确后，即可实施。）