NetBSD禁止AI代码提交新规则

提交指南

以下提交指南规定了本项目向源码树提交代码的标准：

只提交你熟悉的代码

只提交你熟悉的代码。如果你不确定计划提交的代码是否可接受（例如，当采用了与问题报告一起提交的代码时），请向熟悉系统该部分的开发者咨询审查意见。如果你是项目新手，请与你的赞助者沟通。

不要提交污染代码到仓库

如果你提交的代码不是由你自己编写的，请仔细检查该代码的许可证是否允许导入到 NetBSD 源代码仓库，以及是否允许自由分发。与代码的作者沟通，确保他们是唯一的作者，并验证他们没有复制任何其他代码。由大语言模型或类似技术（如 GitHub/Microsoft 的 Copilot、OpenAI 的 ChatGPT 或 Facebook/Meta 的 Code Llama）生成的代码被认定为污染代码，未经核心团队事先书面批准，不得提交。

不要提交来自外部树的代码

不要提交来自非 cvs.NetBSD.org 的任何地方检出的树的代码。需要注意的是，所有开发者都可以访问 cvs.NetBSD.org 上的私有 rsync-over-ssh 服务。

更改越具侵入性，所需的事先批准级别就越高

"明显"的修复可以在没有任何事先讨论或审查的情况下提交。（GCC 项目中"明显"的定义是："不可能导致任何人反对。"我们在这里采用了这个定义）

所有其他（即"非明显"的）修复应该经过审查。

实现（重要的）新功能需要在适当的技术邮件列表上进行事先讨论。

添加全新的软件包（例如 openldap）需要在邮件列表上进行事先讨论并获得核心团队的批准。

只提交你已测试过的代码

确保你的代码按预期工作，通过使用系统工具编译并运行受你变更影响的代码。如果你更改了 man 页面，确保 groff/nroff 能生成你预期的格式化 man 页面。

对于常规提交（到主干），测试你的代码是否在 -current 上工作。在请求向分支拉回前，在相应的发布分支上测试你实际将从 releng 请求的变更。

运行 /usr/tests 中的所有相关测试，理想情况下运行完整的测试套件。检查每日构建和自动化测试运行。长期回归（构建损坏或测试失败）是不可接受的，如果不解决回归问题，导致这些回归的变更将被撤销。

将属于同一修复的提交组织在一起

一起处理多个 Makefile 的 make 变量重写应该在一个提交中完成。

每个提交应该是一个单独的补丁/修复/添加等

不要用同一个提交修复 3 个 bug，并将其汇总为"修复了一些 bug"。修复一个，测试，提交，重复。这大大方便了 releng 拉回修复，因为常常不是所有内容都适用于给定的分支。

不要混合功能或 bug 修复补丁与空白/布局更新

分别进行这些操作（除了通常要求以易于识别每个修复做了什么的方式进行变更之外，当混合空白与功能修复时，会在从主干到分支的大量变更文件的拉回问题上出现）。

在提交日志中清晰记录变更的原因

详细说明变更了什么以及为什么。这不需要是代码审查/演示，但应该对 6 个月后阅读日志并查看 diff 的人有所帮助。重点应该放在"为什么"上，因为阅读日志的目标读者通常可以从查看 diff 中理解"是什么"。作为练习，请考虑"将 i 设置为 1"和"正确初始化迭代器以修复内存处理中的罕见触发 bug"之间的有用性差异。同样，"修复了一些东西"或"cvs-1.10.0"没有信息量，但以下示例有：

"在执行 .for 指令时输出有用的行号。"

如果你的变更修复了一个 PR，请用适当的消息记录它。在提交消息中使用模板 "PR category/bug-id" 也会将其附加到我们的 bug 数据库中的相应问题报告中：

"Closes PR bin/6666"

如果你的代码已被其他人审查过，请记录这一点：

"Reviewed by <mrg>"

（请注意，良好的提交日志不能替代程序本身的良好文档。）

给予适当的信誉

如果你提交的代码是在 PR 中提交的，请给予适当的信誉，例如：

"Code submitted in PR lib/393939 by Joe Doe"

由于提交消息最终会出现在 source-changes 邮件列表中，该列表也可以通过网络获取，通常应避免指定 PR 提交者的电子邮件地址。

如果你从其他开源项目中获取了代码，请给予信誉，例如：

"From FreeBSD"

不要撤销其他开发者的提交

如果你不同意另一个开发者的提交，不要自己撤销它。联系该开发者，向他们解释你对相关提交的问题。请该开发者撤销这些变更，而不是你自己做。如果无法达成一致，请联系核心团队 core@NetBSD.org，他们将作为调解机构。