这是针对英文原版页面的中文翻译。

GNU 开发资源

本页面旨在为GNU工程的开发人员介绍GNU为他们提供的诸多开发资源。想要了解GNU维护人员的详细职责，请参看GNU维护人员参考信息，且需遵循GNU编码规范。同时，这篇GNU维护人员技巧和这篇什么是GNU软件包也会有帮助。

随着能运行GNU/Linux的廉价计算机的丰富, 以及因特网访问服务实用性的增强, 许多GNU志愿者今天拥有他们所需要的全部计算机设施。可是，拥有中央计算机仍然有它的优点，在这儿，GNU志愿者们可以在一起工作而不必把他们自己机器的权限给别人。

因为这个原因，自由软件基金会(FSF)鼓励GNU软件工程像在家一样使用gnu.org上的机器。对这些机器的使用也间接的有利于GNU工程，通过增加公众对GNU的注意，传播为了有利于每一个人的在一起工作的思想。

Savannah 和版本控制

倘若您在开发 GNU 的官方软件，我们强烈建议您使用 Savannah 为您提供的公开的版本控制系统。若要使用它，首先请 创建一个个人账号，然后注册你的 GNU 软件包。之后，您可以选择一个版本控制系统，创建一些网页，给代码贡献者不同权限，以及其他的相关设置。

邮件列表

我们为GNU软件包提供必须的邮件列表，包括手动管理列表和自动管理列表。

当 GNU 软件包在 Savannah 注册时, 会有一个网络界面允许开发者建立和管理该软件包专用的邮件列表。

对于每个 GNU 软件，倘若其名为 name，那么至少得有个叫做 bug-pkgname@gnu.org 的邮件列表，用来汇报 bug，还可以给这列表起几个别名。使用 Savannah，你可以为自己项目创建符合规范的列表。有些软件包共享列表 bug-gnu-utils@gnu.org 用来汇报 bug，但是我们现在强烈建议每个软件包建立各自独立的列表。

软件包可以拥有用于公告、寻求帮助、放入相关的源代码、用户间讨论以及其他软件包的维护者认为有用的邮件列表。

自动管理的邮件列表归档于lists.gnu.org（mbox的归档可以通过HTTPS获取），也可以通过列表管理获取。手动管理的邮件列表归档于GNU机器的/com/archive。

当邮件列表太大了而不能证明其有效性，我们可以建立一个gnu.*的新闻组，它双向链接到邮件列表中。

网页服务

GNU 的主站点位于 www.gnu.org。我们强烈建议 GNU 软件包使用 https://www.gnu.org/software/pkgname 作为它们的官方首页。

使用 Savannah，开发人员可以使用上述 url，通过 CVS 的 “网页仓库” 来创建和维护他们的项目主页。这个仓库和软件包的主仓库（它可以使用其他受支持的版本管理程序）是分开的。请参看 关于 GNU 网页维护的更多信息。

FTP

为 GNU 软件提供 FTP 服务的站点在 https://ftp.gnu.org/gnu/。它在世界各地也有 镜像。我们强烈建议您把您所维护的 GNU 软件包上传至此（当然，也可以再另外上传到您觉得方便的地方）。

我们为测试版本使用不同的服务器，因此人们不会因为它们已经准备好了而安装它们，这个服务器是 https://alpha.gnu.org/。

在GNU维护人员手册中，描述了详细的FTP上传的整个流程。这在上述服务器中均适用。

登录账号

倘若 GNU 软件开发人员需要 shell 登录，我们可以为他们提供此服务，让他们登录到 GNU 的机器上。不过需要注意，使用这样的登录账户既拥有权利，也同时肩负着责任。这些账号必须只能用来做和 GNU 工程相关的工作。详情参考 如何获得登录账号。

在所登陆的计算机上，gsrc 的开发者们维护着一个当前 GNU 软件包的资料库。这些软件均直接编译自各个软件的源代码。若要使用，请输入命令 source /gd/gnu/gnusys/live/setup。

您也可以 使用一个 GNU 账号来发邮件。

Hydra: 持续构建（Continuous builds）与可移植性测试

持续构建工具（continuous build tools，通常也被叫做持续集成工具—continuous integration tools）可以在代码被加入项目后，迅速地找到其中的编程错误。这对于团队合作开发软件非常有帮助。

Hydra 是一款基于 Nix 的自由的持续构建工具。代尔夫特理工大学 Hydra 项目组 的管理员们慷慨地为 GNU 项目提供了一片空间。Hydra 管理的项目会对每次提交或依赖关系更改（依赖关系包括标准构建环境，就是指 GCC 更新、GNU make 更新等等）进行重新集成。

目前，Hydra 支持在 GNU/Linux（i686和x86_64）、FreeBSD、Darwin、Solaris 以及 Cygwin 下构建软件，同时也支持交叉编译其他体系结构或 MinGW 上的 GNU/Hurd、GNU/Linux 系统。它提供利用 LCOV 生成的代码覆盖报表。除了源代码压缩包和 Nix 包以外，它还可以为基于 deb- 或 RPM 软件包的发行版打包。软件包可以基于最新的依赖库来构建。比如，GnuTLS 需要用到 GNU libtasn1 和 GNU libcrypt，那么就可以基于这两个库的最新版本来构建它。

除了 网络界面 以外，Hydra 可以在项目构建状态发生改变的时候，通过电子邮件来提醒管理人员——比如，从 SUCCEEDED 状态变为了 FAILED）。当构建失败时，日志和构建树可以通过网络界面获取；后者允许审查已创建的文件（比如，config.log 或 testsuite.log），这样就可以获得处理故障的信息。

任何一个 GNU 软件包都可以申请在 Hydra 上的一片空间。每个软件包必须提供一份“构建策略”。该策略使用 Nix 语言编写（用 Nix 的术语来说，就是 Nix表达式）。GNU 项目通用 Nix 表达式范本可以在 Git 上获取。对于简单的项目来说，使用标准的 GNU 构建程序的话，比如 Automake 和 Autoconf，这份构建策略通常非常简单。比如可以参考这个 GNU Patch 构建策略。对此您有任何问题，欢迎向 hydra-users@gnu.org提问。

在编写完您的构建策略之后，请把它发至 hydra-users@gnu.org，并要求把它加入到 Hyra。同时确保它是 hydra-recipesSavannah 项目 的成员。这样你就可以直接定制自己项目的构建工作了。

关于 Hydra 的技术信息，请参考 Hydra 手册。更多细节，请参考 Nix 手册。

平台测试者：手动可移植性测试

另一项发布前测试选项是 平台测试者邮件列表。如果时间允许，该邮件列表成员会根据需求在多种平台上构建预先发布版本。（我们征求测试志愿者！只需加入该邮件列表就可以开始介入了。）

和上面提到的 Hydra 工具不同，平台测试者主要进行手动测试，两种方法各有优劣。另外，平台测试者了解比设置 Hydra 更多种类的平台和编译器。

所以，如果你有预发布版，你可以发信给邮件列表，提供(1) 压缩包的url，(2) 计划的发布日期，和(3) 收取构建报告的电子邮件地址。构建和报告都有列表里的志愿者手动完成。