1.1. 为什么选择此文档？

有大量良好的实践传统帮助他人移植、使用和合作的开源代码开发它。其中一些约定在Unix中是传统的世界和Linux之前；另一些是最近针对特定的新工具和技术，如万维网网状物。

本文档将帮助您学习良好实践。它是有组织的分为主题部分，每个部分包含一系列清单项。想想这些是您的补丁或软件的飞行前检查清单分布。

翻译成德国的可用。

1.2. 本文档的新版本

此文档将每月发布到新闻组comp.os.linux.answers公司.你也可以在万维网上查看此HOWTO的最新版本通过URLhttp://tldp.org/HOWTO/Software-Release-Praction.html.

请随时将有关本HOWTO的任何问题或意见发送至埃里克·雷蒙德，<电子邮箱：snark.thyrsus.com>.

2.1. 发送修补程序，不发送整个存档或文件

如果您的更改包含代码中不存在的新文件，当然，您必须发送整个文件。但如果你在修改一个已经存在的文件，不要发送整个文件。改为发送差异；具体来说，发送差异(1)命令运行以将基线分布式版本与您的修改版本。

diff命令及其双重命令，补丁(1)（自动将差异应用于基线文件）是开源开发最基本的工具。差异更好而不是整个文件，因为您要向5月份的开发人员发送补丁收到副本后，已更改了基线版本。通过发送他与你不同，你为他节省了将你的更改与他的更改分离的努力；你尊重他的时间。

2.2. 针对当前版本的代码发送修补程序。

派遣维护人员既适得其反又粗鲁无礼针对之前几个版本中存在的代码进行补丁他要做所有的工作来确定哪些改变了重复的事物从那以后，与你的补丁中哪些东西实际上是新颖的相比。

作为补丁提交者，它是你的责任跟踪源的状态并向维护者发送一个最小的补丁它表示您希望对主线代码库执行的操作。这意味着针对当前版本发送修补程序。

如今，所有开源项目都有效地生成了源代码可通过公共匿名访问项目的版本控制收回权。确保您正在修补当前是从项目的存储库。所有版本控制系统都有一个命令，允许您区分你的工作副本和头部；使用它。

2.3。不要为生成的文件包含修补程序。

在发送修补程序之前，请仔细检查并删除任何其中要自动重新生成的文件的修补带一旦他应用补丁并重新制作。这方面的经典例子错误是C文件由野牛或弯曲.

这些天来，这种最常见的错误是发送一个diff用一个巨大的乐队，在你的配置脚本和他的。此文件由生成自动配置文件.

这是不体谅人的。这意味着你的收件人遇到了麻烦将补丁的真实内容从大量庞大的噪声中分离出来。这是一个小错误，不如我们将得到的一些东西重要继续下去，但这对你不利。

如果您已经签出，您可能会自动避免这种情况来自项目报告的代码并使用版本控制系统的差异命令生成修补程序。

2.4. 不要发送只调整版本控制$-符号的补丁带。

有些人在源文件中放置特殊标记签入文件时由版本控制系统展开：美元Id$RCS、CVS和例如，颠覆。

如果您自己使用本地版本控制系统可以更改这些标记。这并不是真的有害，因为当你收件人在应用了他们将获得的修补程序后重新签入他的代码基于重新扩展他的版本控制状态。但是那些额外的贴片带是噪音。他们在分散注意力。还有更多考虑不发送它们。

这是另一个小错误。如果你这样做，你会被原谅的把大事做好。但你无论如何都要避免。

2.5. 请使用-c或-u格式，不要使用默认（-e）格式

的默认（-e）格式差异(1)非常脆弱。它不包含任何上下文，因此补丁工具无法处理基线中是否插入或删除了任何行代码，因为您获取了修改后的副本。

获得-e diff很烦人，这表明发送者要么是一个极端的新手，要么粗心大意，要么一无所知。大多数此类补丁毫不犹豫地被淘汰出局。

2.6。务必在修补程序中包含文档

这非常重要。如果您的补丁使用户可见添加或更改软件功能，包括对修补程序中适当的手册页和其他文档文件.做不假设收件人愿意为您记录代码，否则将隐藏未记录的功能在代码中。

很好地记录您的更改可以展示一些好的东西。第一，这对你想说服的人来说很体贴。第二，它表明你很好地理解了变化的后果向看不到代码的人解释。第三，它证明了你关心最终使用软件的人。

良好的文档通常是区分一次快速而肮脏的黑客活动做出了坚实的贡献。如果你慢慢来并且小心生产，你会发现你已经是让补丁被大多数开发人员接受的方法。

2.7. 务必在补丁中包含说明

你的补丁应该包括封面说明，解释为什么你认为补丁是必要的或有用的。这是一个不针对软件的用户，但发送给您要接收的维护者补丁。

笔记可以很短，事实上，一些最有效的我见过的封面注释只是说“请参阅此中的文档更新补丁”。但它应该表现出正确的态度。

正确的态度是有益的，尊重维护者的时间，平静自信但谦逊。最好表现出对你正在修补的代码。很好地表明，您可以认同维修人员的问题。坦诚面对任何风险也很好在使用贴片时感知。以下是几种类型的示例我喜欢在封面注释中看到的解释性评论：

"我看到这个代码有两个问题，X和Y。我解决了问题X，但我没有尝试解决问题Y，因为我认为我不理解我认为涉及的代码部分。"

"修复了当一个foo输入过长时可能发生的核心转储。当我在那里的时候，我去其他地方寻找类似的溢出。我在blarg.c的666号线附近发现一个可能的。你确定是发送者吗每次传输不能生成超过80个字符？"

"你考虑过用Foonly算法解决这个问题吗？那里是一个很好的实现<http://www.somesite.com网站/~jsmith/foonly.html>。"

"这个补丁解决了眼前的问题，但我意识到它使内存分配方式令人不快。对我有用，但你应该可能在装运前在重载下进行测试。"

"这可能是featurititis，但无论如何我都会发送它。也许你会知道以更干净的方式实现该功能。"

2.8. 在代码中包含有用的注释

通常作为一名维护者，我想对自己在合并之前了解您的更改。这不是一成不变的规则；如果你有良好的工作记录，我可能会和你一起在半自动检查之前，会对更改进行随意的检查。但您可以做的一切都是为了帮助我理解您的代码并减少我的不确定性增加了我接受你的补丁的机会。

你代码中的好评论有助于我理解它。差评论不要。

下面是一个不好的评论示例：

/*诺曼新手于2009年8月13日修复*/

这不传达任何信息。这只是一片泥泞的土地你在我的代码中间植入的引导。如果我拿走你的补丁（你说的可能性不大）我几乎肯定会去掉这个评论。如果你想获得学分，请为项目提供一个接插带新闻或历史文件。我将可能会接受。

下面是一个好的评论示例：

/**需要保护此条件，以便crunch_data（）*永远不会传递NULL指针<norman_newbie@foosite.com>*/

此注释表明您不仅理解我的代码，而且还理解这类信息我需要对您的更改有信心。这种评论给予我对你有信心变化。

2.9. 每个补丁只有一个错误修复或新功能。

不要收集各种错误修复、新功能或其他东西将它们作为一个diff文件发送。相反，为每个错误修复或功能。应使用电流生成每个差异代码的版本，不应依赖于您或其他人的任何其他修补程序之前发送的其他。

这有助于维护人员阅读和理解您的代码，并且他可以决定他是否接受或放弃这个单一的错误修复或功能。例如，如果您添加了一个为每个人提供完全根访问权限的功能因为它在您的特殊设置中很有用，所以维护人员可能不会接受补丁的这一部分。当您发送单个差异文件时这个根访问功能以及一些错误修复和其他有用的功能很有可能维护者会忽略您的完整补丁。

将每个错误修复和新功能作为单个diff文件例如，维护人员可以在几分钟内修复您的错误，稍后再进行仔细查看您的新功能或安全问题。

依赖于其他修补程序的修补程序会引发类似问题。如果维护者拒绝了您的基本补丁，他将无法应用其他。如果您无法避免这种依赖性，请向维护人员提供你将把补丁与他想要的部分或功能捆绑在一起添加。

3.1. 将GNU样式的名称与词干和major.minor.patch编号一起使用。

如果您的存档文件都具有类似GNU的特性，这对每个人都有帮助names—全小写字母数字词干前缀，后跟破折号，后面是版本号、扩展名和其他后缀。

假设您有一个在版本1中称为“foobar”的项目，版本2，级别3。如果它只有一个存档部分（可能是源代码），其名称应如下所示：

拜托不要使用这些：

如果必须区分源存档和二进制存档，或在不同类型的二进制文件之间，或表示某种构建选项，请将其视为文件扩展名之后版本号。也就是说，请这样做：

拜托不要使用类似这样的名称`foobar-ELF-1.2.3.tar.gz’，因为程序很难判断从茎上键入内缀（如“-ELF”）。

一个好的通用名称应按以下顺序排列：

1. 项目前缀

2. 短跑

3. 版本号

4. 点

5. “src”或“bin”（可选）

6. 点或破折号（首选点）

7. 二进制类型和选项（可选）

8. 存档和压缩扩展

3.2. 但在适当的地方尊重当地惯例

一些项目和社区对名称和不一定与上述建议兼容的版本号。例如，Apache模块通常命名为mod_foo，并且具有他们自己的版本号和使用的Apache版本工作。同样，Perl模块的版本号可以被视为浮点数（例如，您可能会看到1.303而不是1.3.3），以及这些发行版的版本通常命名为Foo-Bar-1.303.tar.gz模块Foo:：Bar的1.303。（另一方面，Perl本身切换到使用1999年末本文件中描述的约定。）

寻求并尊重专业惯例社区和开发商；对于一般用途，请遵循上述步骤指导方针。

3.3. 尽量选择唯一且易于键入的名称前缀

词干前缀应该易于阅读、键入和记忆。所以请不要使用下划线。不大写或双大写非常好的理由-它扰乱了自然的人眼搜索秩序等。

当两个不同的项目有相同的主干时，人们会感到困惑名称。因此，在首次发布之前，请尝试检查碰撞。谷歌是你的朋友-如果你正在考虑的茎得到了很多谷歌点击，这本身可能就足以让你想出一个不同的。另一个检查的好地方是应用程序索引位于自由代码和SourceForge公司; 进行姓名搜索那里。

4.1. 开源和版权

任何非公共领域的东西都有版权，可能超过一个。根据伯尔尼公约（自1978年以来一直是美国法律），版权不必明确。也就是说即使没有版权声明，作品也拥有版权。

谁算作者可能很复杂，尤其是对于由许多人开发的软件。这就是许可证的原因都很重要。通过列出材料可以使用时，它们将保护用户免受任意攻击的权限授予用户版权所有者的行为。

在专有软件中，许可条款旨在保护版权。它们是授予某些权利的一种方式用户，同时为所有者（版权所有者）。版权所有者非常重要，许可逻辑如此严格，以至于许可条款通常并不重要。

在开源软件中，情况通常正好相反；版权的存在是为了保护许可证。唯一的权利版权所有者始终坚持执行许可。否则，只有少数权利被保留，大多数选择都传递给用户。在特别是，版权所有者不能更改您的副本上的条款已经有了。因此，在开源软件中，版权所有者这几乎无关紧要，但许可条款非常重要。

通常项目的版权所有者是当前的项目负责人或赞助组织。项目转移至一个新的领导者经常会通过改变版权所有者来发出信号。然而，这并不是一个硬性规定；许多开源项目有多个版权持有人，并且没有记录在案的这导致了法律问题。

一些项目选择将版权授予自由软件基金会，关于它有兴趣为开源和律师辩护的理论可以这样做。

4.2. 什么是开源

出于许可目的，我们可以区分几个不同的许可证可能传递的各种权利。权利复制并重新分配，权限使用,权利修改以供个人使用，以及重新分发修改的副本。许可证可以对这些权利进行限制或附加条件。

这个开放源代码主动权是大量思考的结果制作软件“开源”或（旧术语）“自由软件”。其对许可证的限制要求：

1. 授予无限复制权。

2. 授予无限使用权。

3. 授予无限修改权供个人使用。

准则禁止限制修改二进制文件；这满足了软件分销商的需求需要能够在没有阻碍的情况下发送工作代码。它允许作者要求将修改后的源重新分配为原始源源代码加上补丁，从而确定作者的意图和“审计跟踪”其他人的任何更改。

OSD是“OSI认证开源”的法律定义认证标志，以及“自由软件”作为任何人都曾想出过。所有标准许可证（MIT、BSD、，Artistic和GPL/LGPL）满足了这一要求（尽管有些，如GPL，还有其他选择之前您应该了解的限制）。

请注意，仅允许非商业使用的许可证不有资格获得开源许可证，即使他们装饰有“GPL”或其他一些标准许可证。他们歧视特定职业、个人和群体。它们使CD-ROM发行商和其他人的生活过于复杂试图在商业上传播开源软件。

5.1. 让自己或FSF成为版权所有者

在某些情况下，如果您背后有一个赞助组织律师，您可能希望将版权授予该组织。

5.2. 使用符合开源定义的许可证

开源定义是社区的黄金标准许可证。OSD本身不是许可证；相反，它定义了许可证必须保证的最小权利集被视为开源许可证。OSD和支持材料，可以在开源倡议.

5.3. 如果可以避免的话，不要编写自己的许可证。

广为人知的符合OSD的许可证已经确立解释传统。开发人员（以及他们关心的用户）了解它们的含义，并合理地承担风险和权衡他们参与其中。因此，请使用OSI站点（如果可能）。

如果您必须编写自己的许可证，请确保获得认证由OSI提供。这将避免很多争论和开销。除非你已经经历过了，你不知道执照有多糟糕火焰战争可以得到；人们之所以充满激情，是因为许可证被视为触及开源社区。

此外，既定解释传统的存在可能如果你的驾照曾在法庭上接受过测试，那么证明这一点很重要。时间写作（2002年初）没有支持或无效的判例法任何开源许可证。然而，这是一种法律原则（至少在美国，可能还有其他公法国家，如英国以及英联邦其他地区）法院应该根据预期和它们起源的社区的实践。

5.4. 使您的许可证在标准位置可见。

随着越来越多的开源软件的部署，审核这些卷的许可证覆盖问题成为重要的是，事实上，它比一个独立的人要大因此，具有支持许可信息的机械化查询。幸运的是，现有社区实践已经朝着这个方向发展。

首先，您的软件的许可证信息应该位于顶级目录中名为COPYING或LICENSE的文件中您的源分发。如果单个许可证适用于整个分发时，该文件应包含许可证的副本。如果有多个许可证适用，该文件应列出适用的许可证和指示它们应用于哪些文件和子目录。

6.1. 选择您能使用的最便携的语言

选择一种开发语言，将它将在其中运行的底层环境。C/C++程序是可能比Fortran更便于移植。Java优于C/C++，Perl、Python或Ruby等高级脚本语言是最好的选择（因为脚本语言只有一种跨平台实施）。

符合条件的脚本语言包括Python、Perl、Tcl、EmacsLisp和PHP。历史Bourne shell（/bin/sh）确实如此不合格；有太多不同具有微妙特性的实现，以及shell环境会受到用户自定义（如shell）的干扰别名。

如果选择编译语言（如C/C++），请不要使用编译器扩展（例如在堆栈，或通过空指针指示）。定期使用尽可能多地使用不同的编译器和测试机器。

6.2. 不要依赖专有代码

不要依赖专有语言、库或其他代码。在开源社区，这被认为是粗鲁的。开放源代码开发人员不信任他们无法查看源代码的代码。

6.3. 构建系统

开源发行版的一个显著优点是它们允许每个源代码包在编译时都要适应它找到的环境。您需要做出的一个选择是“构建系统”，即您需要的工具箱（和其他人）将依赖于将您的源转换为可执行文件。

构建脚本不能做的一件事是要求用户提供系统编译时的信息。安装软件包的用户不会必须知道问题的答案，所以这种方法注定要失败从一开始。调用构建系统工具的软件必须能够自行确定编译时可能需要的任何信息，或安装时间。

构建系统最佳实践的社区理念现在（最近）2010年）在一个开始的一些变化。

6.4. 在发布之前测试代码

一个好的测试套件允许团队为测试，然后在发布之前轻松运行回归测试。创建强大、可用的测试框架，以便您可以增量添加测试无需培训开发人员测试套件的复杂性。

分发测试套件允许用户社区进行测试将端口分配回组之前。

鼓励您的开发人员使用各种各样的平台他们的桌面和测试机器，使代码不断作为正常开发的一部分，测试可移植性缺陷。

6.5. 发布前检查代码是否正确

如果您使用GCC编写C/C++，请使用-Wall和在每次发布之前清除所有警告消息。编译代码每个编译器都有不同的编译器不同的问题。具体来说，在真64位上编译软件机器。底层数据类型可以在64位计算机上更改，并且经常会在那里发现新的问题。查找UNIX供应商的系统并运行软件上的lint实用程序。

运行用于内存泄漏和其他运行时错误的工具；电动围栏和瓦尔格林德开源中有两个很好的版本。

对于Python项目PyChecker软件程序可以是一个有用的检查。它还没有超过测试版，但无论如何经常捕捉到一些重要的错误。

如果您正在编写Perl，请使用Perl-c检查代码（可能还有-T、 如果适用）。虔诚地使用perl-w和“Use strict”。（请参阅Perl文档以供进一步讨论。）

6.6条。健全性-在发布之前检查您的文档和README

拼写检查文档、自述文件和错误消息在您的软件中。邋遢代码，当编译和README文件或错误消息中的拼写错误用户相信其背后的工程也是偶然的草率的。

6.7. 推荐的C/C++可移植性实践

如果您正在编写C，请随意使用完整的ANSI特性。具体来说，一定要使用函数原型，这将有助于您发现跨模块不一致。老式的K&R编译器是历史。

不要假设编译器特定的功能，例如GCC“-pipe”选项或嵌套函数可用。这些都会出现咬你第二个人端口到非Linux，非GCC系统。

可移植性所需的代码应隔离到单个区域和一组源文件（例如，“os”子目录）。具有可移植性的编译器、库和操作系统接口问题应该抽象到这个目录中的文件中。这包括变量（如“errno”）、库接口（如“malloc”）和操作系统接口，如“mmap”。

可移植性层使新的软件端口更容易实现。它是通常情况下，开发团队的任何成员都不知道移植平台（例如，有数百种不同的嵌入式操作系统，没有人知道任何重要的部分）。通过创建单独的可移植层知道端口平台的人可以在没有来理解它。

可移植层简化了应用程序。软件很少需要更复杂的系统调用（如mmap或stat和程序员通常配置这样复杂的接口错误地。具有抽象接口的可移植层（“__file_exists”而不是调用stat）仅允许导出系统中有限的、必要的功能，简化了应用程序中的代码。

始终编写可移植层以根据功能进行选择，从不基于平台。尝试创建单独的可移植层对于每个支持的平台，都会导致多次更新问题维护噩梦。始终至少在两个平台上选择“平台”axes：编译器和库/操作系统版本。在一些例如，当Linux供应商选择C库时，有三个轴独立于操作系统版本。有M家供应商，N家编译器和O操作系统版本，“平台”数量快速扩展到除了最大的开发团队之外的任何团队都无法触及的范围。通过使用ANSI和POSIX 1003.1等语言和系统标准，特征集是相对受限的。

可移植性选择可以沿着代码行或编译文件。如果你选择了替代方案，那也没什么区别平台上的代码行或几个不同的文件之一。一条规则拇指是将不同平台的可移植性代码移动到单独的当实现出现明显分歧时的文件（共享内存UNIX与Windows上的映射），并将可移植性代码保留在单个当差异最小时（使用gettimeofday，clock_gettime、ftime或time以查找电流时间）。

避免使用“off_t”和“size_t”等复杂类型。它们各不相同从一个系统到另一个系统的大小，特别是在64位系统上。限制您的在可移植层使用“offt”，以及使用“sizet”只表示内存中字符串的长度，其他什么都不表示。

不要踩到系统任何其他部分的名称空间，（包括文件名、错误返回值和函数名）。在哪里？名称空间是共享的，记录您使用。

选择编码标准。关于标准选择的争论可以永远持续下去——无论如何，这太难了，太贵了维护使用多种编码标准构建的软件，等等必须选择编码标准。无情地执行编码标准，因为代码的一致性和清洁性是最重要的；编码标准本身的细节是遥不可及的。

7.1. 确保tarball总是解压缩到一个新目录中

新手开发人员犯的最令人讨厌的错误就是构建将发行版中的文件和目录解压缩到当前目录，可能会步进已经位于其中的文件。永远不要这样！

相反，请确保存档文件都有一个公共目录部分以项目命名，因此它们将分解为单个顶级直接目录在下方当前版本。

这里有一个makefile技巧，假设您的分发目录是名为“foobar”且SRC包含您的分发文件列表，实现这一点。SRC还可以包含以下子目录的名称：被完整地包括在内。

foobar-$（VERS）.tar.gz：@查找$（SRC）-type f | sed s:^：foobar-$（VERS）/：>MANIFEST@（cd..；ln-s foobar foobar-$（VERS））（cd..；tar-czvf foobar/foobar-$（VERS）.tar.gz`cat foobar/MANIFEST`）@（cd..；rm foobar-$（VERS））

7.2条。进行自述

有一个名为自述文件或阅读。我这是你的来源路线图分配。按照古老的惯例，这是第一个无畏的档案探险家将在解压缩源代码后阅读。

自述文件中的优点包括：

1. 项目的简要描述。

2. 指向项目网站的指针（如果有一个）

3. 关于开发人员构建环境和潜在的可移植性问题。

4. 描述重要文件和子目录的路线图。

5. 生成/安装说明或指向文件的指针包含相同的（通常安装).

6. 维护者/学分列表或指向包含相同内容的文件（通常信用).

7. 最近的项目新闻或指向文件的指针包含相同的（通常新闻).

7.3. 尊重并遵循标准文件命名惯例

在阅读自述之前，你勇敢的探险家会已经扫描了解压缩文件的顶级目录中的文件名分配。这些名字本身可以传递信息。由遵循某些标准命名实践，您可以探险家关于下一步要看什么的宝贵线索。

下面是一些标准的顶级文件名及其含义。不是每个发行版都需要所有这些。

请注意，使用全大写名称的文件名的总体约定是关于包的人可读元信息，而不是构建组件（TAGS是第一个组件的例外，但不是第二个组件的除外）。

有一个常见问题解答可以帮你省去很多悲伤。当关于项目经常出现，把它放在常见问题解答中；然后指导用户阅读发送问题或错误报告前的常见问题解答。培养良好的常见问题解答可以减少项目维护人员的支持负担震级或以上。

每个版本都有一个带有时间戳的历史或新闻文件是有价值的。除其他外，如果你曾经受到专利侵权诉讼的打击（这还没有发生在任何人身上，但最好做好准备）。

7.4. 可升级性设计

随着新版本的发布，您的软件将随着时间的推移而更改。一些这些变化中的任何一个都不会向后兼容。因此，您应该认真考虑设计安装布局您的代码的多个安装版本可以在同一个版本上共存系统。这对图书馆尤其重要——你不能依靠所有客户端程序与您的API更改。

Emacs、Python和Qt项目具有良好的处理约定这；版本号目录。以下是如何安装Qt库层次结构外观（${ver}是版本号）：

/usr/lib/qt/usr/lib/qt-${ver}/usr/lib/qt-${ver}/bin#查找moc的位置/usr/lib/qt-${ver}/lib#查找位置.so/usr/lib/qt-${ver}/include#查找头文件的位置

有了这个组织，您可以有多个版本共存。客户端程序必须指定其库版本想要，但这是因为没有接口而付出的一个小代价打断他们。

7.5. 提供校验和

为二进制文件（tarball、RPM等）提供校验和。这个将允许人们验证他们没有被损坏或其中插入了特洛伊木马代码。

虽然有几个命令可以用于此目的（例如作为总和和校验和)最好使用加密哈希函数。GPG包提供了以下功能功能，通过-分离设计期权；GNU也是如此命令md5总和.

对于您发送的每个二进制文件，您的项目网页应该列出校验和以及用于生成它的命令。

8.1. 文档格式

以下是目前广泛使用的文档标记格式开源开发人员。当我们谈到“表示”标记时，我们的意思是显式控制文档外观的标记（例如字体更改）。当我们谈到“结构化”标记时，我们指的是描述文档的逻辑结构（如分节符或强调标记。）当我们谈到“索引”时，我们指的是过程从文档集合中提取可搜索集合用户可以使用主题指针来可靠地查找材料整个系列都很有趣。

8.2. 良好做法建议

自2000年以来，文件编制实践发生了变化开源项目组（包括Linux内核项目、GNOME、KDE、，自由软件基金会和Linux文档项目）同意一种比传统Unix的面向打印的方法更适合网络工具。自从XML-DocBook工具链达到2001年年中的生产状况，是这样的吗：

1. 在XML-DocBook或asciidoc中维护文档主控形状。甚至您的手册页也可以是DocBook参考条目文件。有一个非常好的HOWTO（世界旅游组织）在编写手册页解释章节和组织您的用户会期待看到。

2. 发送XML或asciidoc主控形状。此外，如果您的用户系统没有圣诞节(1)（自7.3起所有Red Hat发行版的标准配置），提供troff来源你可以通过在你的母版上运行转换来获得。您的软件发行版的安装过程应安装在通常的方式，但如果人们想写，可以直接指向XML/asciidoc文件文档修补程序。

   很容易判断制作(1)保存生成的man文件到目前为止。只需在生成文件中执行以下操作：

   foo.1:foo.xmlxmlto man foo.xml

   如果你使用的是腹水，应该有这样的东西：

   foo.1:foo.txtasciidoc--backend=docbook foo.txtxmlto man foo.xml

3. 从主控形状生成XHTML（使用圣诞节xhtml格式，或直接使用阿西里多克)并做到可从项目的网页上获得，用户可以在其中按顺序浏览决定是否下载代码并加入项目。

要将troff格式的旧文档转换为DocBook，结账文档提升器.如果你是不愿意放弃使用人工源作为主格式，至少尝试一下把它们清理干净文档提升器可以举起它们自动转换为XML。

9.1. 向Freecode发布

请参见自由代码.分发手表查看何时发布新版本的频道。

9.2. 有一个网站

如果您打算建立任何实质性的用户或开发人员社区围绕你的项目，它应该有一个网站。标准的东西网站上包括：

• 项目章程（为什么存在，受众是谁等）。

• 下载项目源的链接。

• 关于如何加入项目邮件列表的说明。

• 常见问题列表。

• 项目文档的HTML化版本

• 相关和/或竞争项目的链接。

一些项目站点甚至有匿名访问主站点的URL源树。

9.3. 主机项目邮件列表

拥有私人发展清单是标准做法项目合作者可以通过它进行沟通和交流补丁。您可能还想为用户提供公告列表希望随时了解项目进程的人。

如果您正在运行名为“foo”的项目。您的开发人员列表可能是foo-dev或foo-friends；您的公告名单可能是美食。

9.4. 向主要档案馆发布

自1999年秋季推出以来，SourceForge公司已经爆炸了很受欢迎。不过，它不仅仅是一个存档和分发站点你可以这样使用它。这是一项完全免费的项目主持服务试图为开源开发小组提供一整套工具-网络和存档空间、邮件列表、错误跟踪、聊天论坛、CVS存储库和其他服务。

其他重要地点包括：

• 这个Python软件活动站点（用于用Python编写的软件）。

• 这个CPAN公司，的综合Perl档案网络，（用于用Perl编写的软件）。

• github、和滑稽的，两个很受欢迎站点提供免费的git存储库访问。