Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst
Source file repositories/reference/linux-study-clean/Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/translations/zh_CN/maintainer/maintainer-entry-profile.rst- Extension
.rst- Size
- 3805 bytes
- Lines
- 93
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. 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,列在概述部分,视为已为新提交做好准备。
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.