Lines Matching +full:- +full:75 +full:mv
1 .. SPDX-License-Identifier: GPL-2.0
5 .. include:: ../disclaimer-zh_TW.rst
7 :Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
28 同樣，:ref:`Documentation/translations/zh_TW/process/submit-checklist.rst <tw_submitchecklist>`
37 -----------------
51 1) "diff -up"
52 -------------
54 使用 "diff -up" 或者 "diff -uprN" 來創建補丁。
57 時候，要確認它是以 "unified diff" 格式創建的，這種格式由 diff(1) 的 '-u'
58 參數生成。而且，請使用 '-p' 參數，那樣會顯示每個改動所在的C函數，使得
71 diff -up $SRCTREE/$MYFILE{.orig,} > /tmp/patch
78 tar xvfz linux-3.19.tar.gz
79 mv linux-3.19 linux-3.19-vanilla
80 diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
81 linux-3.19-vanilla $MYSRC > /tmp/patch
94 如果你用 ``git`` , ``git rebase -i`` 可以幫助你這一點。如果你不用 ``git``,
100 ---------------
136 自郵件列表討論，請給出郵件列表存檔的URL；使用帶有 ``Message-ID`` 的
142 如果您想要引用一個特定的提交，不要只引用提交的 SHA-1 ID。還請包括提交的一行
150 您還應該確保至少使用前12位 SHA-1 ID. 內核存儲庫包含*許多*對象，使與較短的ID
155 12個字符SHA-1 ID 的"Fixes:"標記和單行摘要。爲了簡化不要將標記拆分爲多個，
156 行、標記不受分析腳本「75列換行」規則的限制。例如::
170 ---------------
192 -------------------
195 :ref:`Documentation/translations/zh_TW/process/coding-style.rst <tw_codingstyle>`
209 - ERROR：很可能出錯的事情
210 - WARNING：需要仔細審查的事項
211 - CHECK：需要思考的事情
216 -----------------
221 的維護人員，那麼Andrew Morton（akpm@linux-foundation.org）將充當最後的維護
224 您通常還應該選擇至少一個郵件列表來接收補丁集的。linux-kernel@vger.kernel.org
230 http://vger.kernel.org/vger-lists.html 上找到它們的列表。不過，也有與內核相關
235 Linus Torvalds 是決定改動能否進入 Linux 內核的最終裁決者。他的 e-mail
236 地址是 <torvalds@linux-foundation.org> 。他收到的 e-mail 很多，所以一般
237 的說，最好別給他發 e-mail。
248 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
256 更改複製到 linux-api@vger.kernel.org。
259 -----------------------------------------------------------
262 ，可以「引用」你的改動很重要，使用一般的 e-mail 工具，他們就可以在你的
265 因爲這個原因，所有的提交的補丁都是 e-mail 中「內嵌」的。
268 如果你使用剪切-粘貼你的補丁，小心你的編輯器的自動換行功能破壞你的補丁
270 不要將補丁作爲 MIME 編碼的附件，不管是否壓縮。很多流行的 e-mail 軟體不
277 請參閱 :ref:`Documentation/translations/zh_TW/process/email-clients.rst <tw_email_clients>`
280 7) e-mail 的大小
281 ----------------
289 ---------------
301 -------------------
307 到正確的位置。在重新提交或聯繫審閱者之前至少等待一周-在諸如合併窗口之類的
311 --------------------
316 11）簽署你的作品-開發者原始認證
317 -------------------------------
320 建議在發送出去的補丁上加一個 「sign-off」 的過程。
322 "sign-off" 是在補丁的注釋的最後的簡單的一行文字，認證你編寫了它或者其他
339 一起提交的個人記錄，包括 sign-off ）被永久維護並且可以和這個項目
344 Signed-off-by: Random J Developer <random@developer.example.org>
349 內部的過程，或者只是指出關於 sign-off 的一些特殊細節。
359 Signed-off-by: Random J Developer <random@developer.example.org>
361 Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org>
367 對回合（back-porters）的特別說明：在提交消息的頂部（主題行之後）插入一個補丁
371 Date: Tue Oct 7 07:26:38 2014 -0400
373 libata: Un-break ATA blacklist
385 12）何時使用Acked-by:，CC:，和Co-Developed by:
386 ----------------------------------------------
388 Singed-off-by: 標記表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。
391 那麼他們可以要求在補丁的變更日誌中添加一個 Acked-by:
393 Acked-by：通常由受影響代碼的維護者使用，當該維護者既沒有貢獻也沒有轉發補丁時。
395 Acked-by: 不像簽字人那樣正式。這是一個記錄，確認人至少審查了補丁，並表示接受。
396 因此，補丁合併有時會手動將Acker的「Yep，looks good to me」轉換爲 Acked-By：（但
399 Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁影響多個子系統，並且
407 Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上工
409 Co-developed-by: 表示作者身份，所以每個共同開發人：必須緊跟在相關合作作者的
411 管作者是通過 From ：還是由 Co-developed-by: 共同開發的。值得注意的是，最後一
420 Co-developed-by: First Co-Author <first@coauthor.example.org>
421 Signed-off-by: First Co-Author <first@coauthor.example.org>
422 Co-developed-by: Second Co-Author <second@coauthor.example.org>
423 Signed-off-by: Second Co-Author <second@coauthor.example.org>
424 Signed-off-by: From Author <from@author.example.org>
432 Co-developed-by: Random Co-Author <random@coauthor.example.org>
433 Signed-off-by: Random Co-Author <random@coauthor.example.org>
434 Signed-off-by: From Author <from@author.example.org>
435 Co-developed-by: Submitting Co-Author <sub@coauthor.example.org>
436 Signed-off-by: Submitting Co-Author <sub@coauthor.example.org>
440 --------------------------------------------------------
442 Reported-by: 給那些發現錯誤並報告錯誤的人致謝，它希望激勵他們在將來再次幫助
443 我們。請注意，如果bug是以私有方式報告的，那麼在使用Reported-by標記之前，請
446 Tested-by: 標記表示補丁已由指定的人（在某些環境中）成功測試。這個標籤通知
450 Reviewed-by：相反，根據審查人的聲明，表明該補丁已被審查並被認爲是可接受的：
456 通過提供我的 Reviewed-by，我聲明：
471 Reviewed-by 是一種觀點聲明，即補丁是對內核的適當修改，沒有任何遺留的嚴重技術
472 問題。任何感興趣的審閱者（完成工作的人）都可以爲一個補丁提供一個 Review-by
474 Reviewed-by: 當由已知了解主題區域並執行徹底檢查的審閱者提供時，通常會增加
477 Suggested-by: 表示補丁的想法是由指定的人提出的，並確保將此想法歸功於指定的
490 ----------------
493 可以使用 ``git format-patch`` 進行正確的補丁格式設置。但是，這些工具無法創建
502 - 一個 "from" 行指出補丁作者。後跟空行（僅當發送修補程序的人不是作者時才需要）。
504 - 解釋的正文，行以75列包裝，這將被複製到永久變更日誌來描述這個補丁。
506 - 一個空行
508 - 上面描述的「Signed-off-by」 行，也將出現在更改日誌中。
510 - 只包含 ``---`` 的標記線。
512 - 任何其他不適合放在變更日誌的注釋。
514 - 實際補丁（ ``diff`` 輸出）。
516 標題行的格式，使得對標題行按字母序排序非常的容易 - 很多 e-mail 客戶端都
517 可以支持 - 因爲序列號是用零填充的，所以按數字排序和按字母排序是一樣的。
519 e-mail 標題中的「子系統」標識哪個內核子系統將被打補丁。
521 e-mail 標題中的「一句話概述」扼要的描述 e-mail 中的補丁。「一句話概述」
525 記住 e-mail 的「一句話概述」會成爲該補丁的全局唯一標識。它會蔓延到 git
528 章。當人們在兩三個月後使用諸如 ``gitk`` 或 ``git log --oneline`` 之類
531 出於這些原因，概述必須不超過70-75個字符，並且必須描述補丁的更改以及爲
558 "---" 標記行對於補丁處理工具要找到哪裡是改動日誌信息的結束，是不可缺少
561 對於 "---" 標記之後的額外註解，一個好的用途就是用來寫 diffstat，用來顯
565 使用 diffstat的選項 "-p 1 -w 70" 這樣文件名就會從內核原始碼樹的目錄開始
572 15) 明確回覆郵件頭(In-Reply-To)
573 -------------------------------
575 手動添加回復補丁的的標題頭(In-Reply_To:) 是有幫助的（例如，使用 ``git send-email`` ）
583 --------------------
596 git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
603 的最簡單方法是讓 ``git`` 使用 ``git request-pull`` 命令爲您完成這些工作。
613 一旦您在Git 中準備了一個您希望有人拉的補丁系列，就用 ``git tag -s`` 創建一
623 git request-pull master git://my.public.tree/linux.git my-signed-tag
626 --------
632 <https://web.archive.org/web/20180829112450/http://linux.yyz.us/patch-format.html>
634 Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
637 <http://www.kroah.com/log/linux/maintainer-02.html>
639 <http://www.kroah.com/log/linux/maintainer-03.html>
641 <http://www.kroah.com/log/linux/maintainer-04.html>
643 <http://www.kroah.com/log/linux/maintainer-05.html>
645 <http://www.kroah.com/log/linux/maintainer-06.html>
647 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
650 Kernel Documentation/process/coding-style.rst:
651 :ref:`Documentation/translations/zh_TW/process/coding-style.rst <tw_codingstyle>`
659 http://halobates.de/on-submitting-patches.pdf