1 .. include:: ../disclaimer-zh_CN.rst
2
3 :Original: Documentation/maintainer/maintainer
4
5 :译者:
6
7 吴想成 Wu XiangCheng <bobwxc@email.cn>
8
9 .. _maintainerentryprofile_zh:
10
11 维护者条目概要
12 ==============
13
14 维护人员条目概要补充了顶层过程
15 统/设备驱动程序本地习惯以及有关
16 来调整他们的期望和避免常见错误
17 是否有机会汇聚到通用实践中。
18
19
20 总览
21 ----
22
23 提供了子系统如何操作的介绍。MAIN
24 但它没有传达其他子系统的本地基
25
26 请考虑以下问题：
27
28 - 当补丁被本地树接纳或合并到上
29 - 子系统是否使用patchwork实例？Patch
30 - 是否有任何机器人或CI基础设施监
31 控接纳补丁？
32 - 被拉入-next的Git分支是哪个？
33 - 贡献者应针对哪个分支提交？
34 - 是否链接到其他维护者条目概要
35 这使得贡献者意识到某维护者可
36
37
38 提交检查单补遗
39 --------------
40
41 列出强制性和咨询性标准，超出通
42 足够健康。例如：“通过checkpatch.pl
43
44 提交检查单补遗还可以包括有关硬
45 是否需要考虑在某个修订版上发布
46
47
48 开发周期的关键日期
49 ------------------
50
51 提交者常常会误以为补丁可以在合
52 可以。事实上，大多数补丁都需要
53 向提交者澄清关键日期（以-rc发布
54 何时需要等待下一个-rc。
55
56 至少需要讲明：
57
58 - 最后一个可以提交新功能的-rc：
59 针对下一个合并窗口的新功能提
60 之后提交的补丁应该明确他们的
61 的充足理由。通常新特性贡献者
62
63 - 最后合并-rc：合并决策的最后期
64 向贡献者指出尚未接受的补丁集
65 接受所有给定的补丁集，但是如
66 等待并在下一个合并窗口重新提
67
68 可选项：
69
70 - 开发基线分支的首个-rc，列在概
71
72
73 审阅节奏
74 --------
75
76 贡献者最担心的问题之一是：补丁
77 指定在重新提交之前要等待多长时
78 整个系列，或私下发送提醒邮件。
79 不能直接从维护者那里得到的反馈
80
81
82 现有概要
83 --------
84
85 这里列出了现有的维护人员条目概
86
87 .. toctree::
88 :maxdepth: 1
89
90 ../doc-guide/maintainer-profile
91 ../../../nvdimm/maintainer-entry-profile
92 ../../../arch/riscv/patch-acceptance
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.