Results of 0 - 1 of about 0 (0.000 sec.)
- 提交补丁 (GNU Guix参考手册)
- @digest: 0c9ed16750576a0d9e2343d7f90e7313
- @id: 74803
- @mdate: 2019-05-19T21:18:28Z
- @size: 14324
- @type: text/html
- content-type: text/html; charset=utf-8
- description: 提交补丁 (GNU Guix参考手册)
- distribution: global
- generator: makeinfo
- keywords: 提交补丁 (GNU Guix参考手册)
- resource-type: document
- #keywords: 补丁 (52554), 分支 (41503), 件包 (34382), 送补 (26533), 丁系 (25546), 捆绑 (25238), 构建 (25051), 进ma (22494), 受影 (22290), 并进 (20163), 赖库 (18382), 响的 (18164), 交补 (17590), 的补 (17590), 坏性 (17406), 跟踪 (16905), 更改 (15480), 个软 (14638), 检查 (13934), 用gu (13551), 包的 (12897), 依赖 (12721), 调用 (12405), 件列 (12339), 邮件 (12244), 系列 (11996), 破坏 (10161), debbugs (10140), 影响 (10060), 合并 (9951), 的平 (9810), 这可 (9771)
- Previous: 代码风格 , Up: 贡献 [ Contents ][ Index ] 14.6 提交补丁 开发是使用Git分布式版本控制系统完成的。因此,对仓库的访问权限不是必须的。我们欢迎以向 guix-patches@gnu.org 邮件列表发送 git format-patch 补丁的方式共享代码。 这个邮件列表的后端是一个Debbugs实例（可以从 https://bugs.gnu.org/guix-patches 访问）,它允许我们跟踪提交的bug。每个发送到那个邮件列表的消息都会被分配一个跟踪数字;之后人们可以通过向 NNN @debbugs.gnu.org 发送邮件来跟进提交（ NNN 是跟踪数字,see 发送补丁系列 ）。 请以ChangeLog格式（see Change Logs in GNU代码规范 ）写commit日志;你可以浏览commit历史里的例子。 提交添加或者修改软件包定义的补丁之前,请过一遍这个检查列表: 如果软件包的作者为发布的文件包提供了密码学签名,请验证文件的真实性。对于独立的GPG签名文件,这可以通过 gpg --verify 命令完成: 花些时间为软件包提供一个合适的简介和描述。更多指导,See 简介和描述 。 运行 guix lint 软件包 , 软件包 是新添加的或修改过的软件包的名字,修复它报告的错误（see 调用guix lint ）。 用 guix build 软件包 命令确保这个软件包可以在你的平台上构建。 我们建议你同时尝试在别的支持的平台上构建这个软件包。你可能没有别的平台的真实的硬件,我们推荐使用 qemu-binfmt-service-type 来模拟它们。为了启用这个功能,把下面这个服务添加到你的 操作系统 配置的服务列表里: (service qemu-binfmt-service-type (qemu-binfmt-configuration (platforms (lookup-qemu-platforms "arm" "aarch64" "mips64el")) (guix-support? #t))) 然后重新配置你的系统。 你之后可以用 --system 参数为不同的平台构建软件包。例如,为armhf,aarch64,或mips64架构构建"hello"软件包,你可以依次运行如下的命令: guix build --system=armhf-linux --rounds=2 hello guix build --system=aarch64-linux --rounds=2 hello guix build --system=mips64el-linux --rounds=2 hello 请确保软件包里不捆绑出现已经被打过包的软件的副本。 有时,软件包为了方便用户,捆绑了依赖库的源代码。然而,当依赖库在发行版里已经存在时,做为一个发行版,我们希望确保这些软件包使用发行版里已有的副本。这提高资源使用率（依赖库只构建一次,存储一份）,并且使发行版更容易管理,如仅在一个地方对某个软件包进行安全更新就可以影响整个系统－－捆绑软件会妨碍这么做。 看一下 guix size （see 调用guix size ）的分析报告。这会让你注意到对其它软件包无意中的引用。它也可以帮助决定是否要把一个软件包分割成几个输出（see 有多个输出的软件包 ）,以及需要使用哪些可选的依赖。特别地,避免把 texlive 添加为依赖:因为它太大了,请使用 texlive-tiny 或 texlive-union 代替它。 对于重要的更改,确保依赖它的软件包没有受到影响。 guix refresh --list-dependent 软件包 会帮你检查（see 调用guix refresh ）。 取决于受影响的软件包的数量,即需要重新构建的数量,commit需要被提交到不同的分支,具体如下: 300个或更少的受影响的软件包 master 分支（非破坏性的更改）。 300至1200个受影响的软件包 staging 分支（非破坏性的更改）。这个分支每隔大约3周会被合并进 master 。对某个主题的更改（如对GNOME系列的更新）可以放进一个特定的分支（如 gnome-updates ）。 超过1200个受影响的软件包 core-updates 分支（可能含有重要的或破坏性的更改）。这个分支每隔大约2.5个月会被合并进 master 。 所有这些分支都被 构建农场 跟踪,并且当一切都被顺利构建时合并进 master 。这使我们在影响到用户之前就能改正问题,并且缩小没有准备好预构建的二进制包的窗口期。 通常, master 之外的其它分支如果最近被评审过,或有一个对应的 -next 分支,则被视为 冻结 状态。如果不清楚该把补丁放到哪里,请在邮件列表或IRC上提问。 检查软件包的构建过程是不是确定性的。这通常意味着检查对软件包的独立构建是否能得到每一个比特都完全相同的结果。 为此,一个简单的做法是在你的机器上多次构建同一个软件包（see 调用guix build ）: guix build --rounds=2 <我的软件包> 这足以查出一批普通的不确定性问题,如构建结果里存在时间戳或随机生成的输出。 另一个选择是使用 guix challenge （see 调用guix challenge ）。当软件包被提交并且被 ci.guix.gnu.org 构建之后,你可以运行这个命令检查你是否得到相同的构建结果。更好的:找另一台可以构建的机器,运行 guix publish 。由于远程的构建机器很可能和你的机器不同,这可以捕捉到由硬件不同引起的不确定性问题－－如,使用不同的指令集－－或不同操作系统内核引起的问题－－如,对 uname 或 /proc 文件的依赖。 在编写文档时,请用性别中立的词语指代人,如 “他”, “他的” ,等。 检查你的补丁只包含一些相关的更改。把不相关的更改捆绑在一起会让评审更困难和更慢。 不相关的更改的例子有:同时新增多个软件包,或更新软件包同时修补这个软件包。 请遵守我们的代码格式规范,最好运行 etc/indent-code.el 脚本以自动为你格式化（see 格式化代码 ）。 当可能时,请在源URL里使用镜像see 调用guix download 。使用可靠的而不是生成的URL。例如,GitHub的下载文件每次生成时不一定是相同的,所以这时最好克隆仓库。不要在URL里使用 name 变量:这没有什么用,而且如果名字变了,URL很可能就错了。 在提交补丁到邮件列表时,使用‘ [PATCH] … '做为主题。你可以使用你的邮件客户端或者 git send-email 命令（see 发送补丁系列 ）。我们倾向于接收纯文本的邮件,无论是在正文里还是在MIME附件里。建议你注意你的邮件客户端是否会自动修改换行或缩进,这可能会损坏补丁。 当一个bug被修复时,请通过向 NNN -done@debbugs.gnu.org 发邮件的方式关闭thread。 发送补丁系列 在发送补丁系列时（如,使用 git send-email ）,请先向 guix-patches@gnu.org 发送一封邮件,再把后续的补丁发送到 NNN @debbugs.gnu.org ,以确保他们被归在一起。见 Debbugs文档 以了解更多信息。
...
-
http://www.gnu.org/savannah-checkouts/gnu/guix/manual/zh-cn/html_node/Ti-Jiao-Bu-Ding-.html
- [detail]
- [similar]
PREV
NEXT