93 lines
3.7 KiB
ReStructuredText
93 lines
3.7 KiB
ReStructuredText
|
.. include:: ../disclaimer-zh_CN.rst
|
|||
|
|
|
|||
|
|
:Original: Documentation/maintainer/maintainer-entry-profile.rst
|
|||
|
|
|
|||
|
|
:译者:
|
|||
|
|
|
|||
|
|
吴想成 Wu XiangCheng <bobwxc@email.cn>
|
|||
|
|
|
|||
|
|
.. _maintainerentryprofile_zh:
|
|||
|
|
|
|||
|
|
维护者条目概要
|
|||
|
|
==============
|
|||
|
|
|
|||
|
|
维护人员条目概要补充了顶层过程文档（提交补丁，提交驱动程序……），增加了子系
|
|||
|
|
统/设备驱动程序本地习惯以及有关补丁提交生命周期的相关内容。贡献者使用此文档
|
|||
|
|
来调整他们的期望和避免常见错误；维护人员可以使用这些信息超越子系统层面查看
|
|||
|
|
是否有机会汇聚到通用实践中。
|
|||
|
|
|
|||
|
|
|
|||
|
|
总览
|
|||
|
|
----
|
|||
|
|
|
|||
|
|
提供了子系统如何操作的介绍。MAINTAINERS文件告诉了贡献者应发送某文件的补丁到哪，
|
|||
|
|
但它没有传达其他子系统的本地基础设施和机制以协助开发。
|
|||
|
|
|
|||
|
|
请考虑以下问题：
|
|||
|
|
|
|||
|
|
- 当补丁被本地树接纳或合并到上游时是否有通知？
|
|||
|
|
- 子系统是否使用patchwork实例？Patchwork状态变更是否有通知？
|
|||
|
|
- 是否有任何机器人或CI基础设施监视列表，或子系统是否使用自动测试反馈以便把
|
|||
|
|
控接纳补丁？
|
|||
|
|
- 被拉入-next的Git分支是哪个？
|
|||
|
|
- 贡献者应针对哪个分支提交？
|
|||
|
|
- 是否链接到其他维护者条目概要？例如一个设备驱动可能指向其父子系统的条目。
|
|||
|
|
这使得贡献者意识到某维护者可能对提交链中其他维护者负有的义务。
|
|||
|
|
|
|||
|
|
|
|||
|
|
提交检查单补遗
|
|||
|
|
--------------
|
|||
|
|
|
|||
|
|
列出强制性和咨询性标准，超出通用标准“提交检查表，以便维护者检查一个补丁是否
|
|||
|
|
足够健康。例如：“通过checkpatch.pl，没有错误、没有警告。通过单元测试详见某处”。
|
|||
|
|
|
|||
|
|
提交检查单补遗还可以包括有关硬件规格状态的详细信息。例如，子系统接受补丁之前
|
|||
|
|
是否需要考虑在某个修订版上发布的规范。
|
|||
|
|
|
|||
|
|
|
|||
|
|
开发周期的关键日期
|
|||
|
|
------------------
|
|||
|
|
|
|||
|
|
提交者常常会误以为补丁可以在合并窗口关闭之前的任何时间发送，且下一个-rc1时仍
|
|||
|
|
可以。事实上，大多数补丁都需要在下一个合并窗口打开之前提前进入linux-next中。
|
|||
|
|
向提交者澄清关键日期（以-rc发布周为标志）以明确什么时候补丁会被考虑合并以及
|
|||
|
|
何时需要等待下一个-rc。
|
|||
|
|
|
|||
|
|
至少需要讲明：
|
|||
|
|
|
|||
|
|
- 最后一个可以提交新功能的-rc：
|
|||
|
|
针对下一个合并窗口的新功能提交应该在此点之前首次发布以供考虑。在此时间点
|
|||
|
|
之后提交的补丁应该明确他们的目标为下下个合并窗口，或者给出应加快进度被接受
|
|||
|
|
的充足理由。通常新特性贡献者的提交应出现在-rc5之前。
|
|||
|
|
|
|||
|
|
- 最后合并-rc：合并决策的最后期限。
|
|||
|
|
向贡献者指出尚未接受的补丁集需要等待下下个合并窗口。当然，维护者没有义务
|
|||
|
|
接受所有给定的补丁集，但是如果审阅在此时间点尚未结束，那么希望贡献者应该
|
|||
|
|
等待并在下一个合并窗口重新提交。
|
|||
|
|
|
|||
|
|
可选项：
|
|||
|
|
|
|||
|
|
- 开发基线分支的首个-rc，列在概述部分，视为已为新提交做好准备。
|
|||
|
|
|
|||
|
|
|
|||
|
|
审阅节奏
|
|||
|
|
--------
|
|||
|
|
|
|||
|
|
贡献者最担心的问题之一是：补丁集已发布却未收到反馈，应在多久后发送提醒。除了
|
|||
|
|
指定在重新提交之前要等待多长时间，还可以指示更新的首选样式；例如，重新发送
|
|||
|
|
整个系列，或私下发送提醒邮件。本节也可以列出本区域的代码审阅方式，以及获取
|
|||
|
|
不能直接从维护者那里得到的反馈的方法。
|
|||
|
|
|
|||
|
|
|
|||
|
|
现有概要
|
|||
|
|
--------
|
|||
|
|
|
|||
|
|
这里列出了现有的维护人员条目概要；我们可能会想要在不久的将来做一些不同的事情。
|
|||
|
|
|
|||
|
|
.. toctree::
|
|||
|
|
:maxdepth: 1
|
|||
|
|
|
|||
|
|
../doc-guide/maintainer-profile
|
|||
|
|
../../../nvdimm/maintainer-entry-profile
|
|||
|
|
../../../riscv/patch-acceptance
|