Documentation/translations/zh_TW/process/5.Posting.rst

Source file repositories/reference/linux-study-clean/Documentation/translations/zh_TW/process/5.Posting.rst

File Facts

System
Linux kernel
Corpus path
Documentation/translations/zh_TW/process/5.Posting.rst
Extension
.rst
Size
14332 bytes
Lines
247
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.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

.. include:: ../disclaimer-zh_TW.rst

:Original: :ref:`Documentation/process/5.Posting.rst <development_posting>`

:Translator:

 時奎亮 Alex Shi <alex.shi@linux.alibaba.com>

:校譯:

 吳想成 Wu XiangCheng <bobwxc@email.cn>
 胡皓文 Hu Haowen <2023002089@link.tyut.edu.cn>

.. _tw_development_posting:

發佈補丁
========

您的工作遲早會準備好提交給社區進行審查，並最終包含到主線內核中。毫不稀奇，
內核開發社區已經發展出一套用於發佈補丁的約定和過程；遵循這些約定和過程將使
參與其中的每個人的生活更加輕鬆。本文檔試圖描述這些約定的部分細節；更多信息
也可在以下文檔中找到
:ref:`Documentation/translations/zh_CN/process/submitting-patches.rst <tw_submittingpatches>`
和 :ref:`Documentation/translations/zh_CN/process/submit-checklist.rst <tw_submitchecklist>`。

何時寄送
--------

在補丁完全“準備好”之前，避免發佈補丁是一種持續的誘惑。對於簡單的補丁，這
不是問題。但是如果正在完成的工作很複雜，那麼在工作完成之前從社區獲得反饋就
可以獲得很多好處。因此，您應該考慮發佈正在進行的工作，甚至維護一個可用的Git
樹，以便感興趣的開發人員可以隨時趕上您的工作。

當發佈中有尚未準備好被包含的代碼，最好在發佈中說明。還應提及任何有待完成的
主要工作和任何已知問題。很少有人會願意看那些被認爲是半生不熟的補丁，但是
那些願意的人會帶着他們的點子來一起幫助你把工作推向正確的方向。

創建補丁之前
------------

在考慮將補丁發送到開發社區之前，有許多事情應該做。包括：

 - 儘可能地測試代碼。利用內核的調試工具，確保內核使用了所有可能的配置選項組合
   進行構建，使用交叉編譯器爲不同的體系結構進行構建等。

 - 確保您的代碼符合內核代碼風格指南。

 - 您的更改是否具有性能影響？如果是這樣，您應該運行基準測試來顯示您的變更的
   影響（或好處）；結果的摘要應該包含在補丁中。

 - 確保您有權發佈代碼。如果這項工作是爲僱主完成的，僱主對這項工作具有所有權，
   並且必須同意根據GPL對其進行發佈。

一般來說，在發佈代碼之前進行一些額外的思考，幾乎總是能在短時間內得到回報。

補丁準備
--------

準備補丁發佈的工作量可能很驚人，但在此嘗試節省時間通常是不明智的，即使在短期
內亦然。

必須針對內核的特定版本準備補丁。一般來說，補丁應該基於Linus的Git樹中的當前
主線。當以主線爲基礎時，請從一個衆所周知的發佈點開始——如穩定版本或 -rc
版本發佈點——而不是在一個任意的主線分支點。

也可能需要針對-mm、linux-next或子系統樹生成版本，以便於更廣泛的測試和審查。
根據補丁的區域以及其他地方的情況，針對其他樹建立的補丁可能需要大量的工作來
解決衝突和處理API更改。

Annotation

Implementation Notes