==================================
ϡ
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt 
Ǥ
Ρ JF ץ < http://www.linux.or.jp/JF/ >
 2006/12/26
 2007/2/5
ԡ Takayoshi Kochi <t-kochi at bq dot jp dot nec dot com>
ԡ Masanori Kobayashi  <zap03216 at nifty dot ne dot jp>
==================================


The perfect patch.
ʤѥå
akpm@osdl.org
Updated 4 March 2006

The latest version of this document may be found at
ʸκǿǤϰʲξ꤫黲ȤǤ롣
http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

Please also see http://linux.yyz.us/patch-format.html
http://linux.yyz.us/patch-format.html ⻲Ȥ뤳ȡ


1: Delivery
1: 
===========

a) Patches are delivered via email only.  Downloading them from internet
   servers is a pain.

   ѥåŻҥ᡼ǤΤƤ뤳ȡ󥿡ͥåȥФ
   ɤΤϤޤʤ

b) One patch per email, with the changelog in the body of the email.

   Żҥ᡼̤ˤĤѥåϰĤˤѹ᡼ʸ
   ˴ޤ뤳ȡ


2: Subject:
2: Subject: (̾)
===========

a) The email's Subject: should concisely describe the patch which that
   email contains.  The Subject: should not be a filename.  Use different
   Subject:s for each patch in a patch series.

   Żҥ᡼ Subject: ϥѥåƤʷ󤹤٤Ǥ롣
   Subject: ϥե̾Τߤˤ٤ǤϤʤϢΥѥå
   Ϥ줾˰ۤʤ Subject: դ뤳ȡ

   Bear in mind that the Subject: of your email becomes a globally-unique
   identifier for that patch.  It propagates all the way into the kernel
   revision control system.  The Subject: may later be used in developer
   discussions which refer to the patch.  People will want to google for the
   patch's Subject: to read discussion regarding that patch.

   Żҥ᡼ Subject: ϥѥåˤĤƤͣμ̻ҤȤʤ뤳Ȥ򿴤
   αƤȡSubject: ϺǽŪ˥ͥΥӥ󥳥ȥ
   ƥˤޤ¤롣˳ȯԤǤΥѥå򻲾Ȥ
   ˤ Subject: ȤȤ⤢ƤΥѥåˤĤƤ
   ɤि Subject:  Google Ǹ͡ФƤ

b) It is nice if the Subject: includes mention of the subsystem which it
   affects.  See example below.

   Subject: ˴Ϣ륵֥ƥ̾ޤƤɤʲ򸫤衣

c) Example Subject:
   Subject:  -

	[patch 2/5] ext2: improve scalability of bitmap searching
        ([patch 2/5] ext2: ӥåȥޥåõΥӥƥ)

        (: ѥåƤϱѸǹԤΤʤΤǡSubject: 
        ᡼Ȥ˴ؤƤϱʸ¤٤ƻȤ롣ʲƱ)

d) Note that various people's patch receiving scripts will strip away
   Subject: text which is inside brackets [].  So you should place information
   which has no long-term relevance to the patch inside brackets.  This
   includes the word "patch" and any sequence numbering.  The subsystem
   identifier ("ext2:") should hence be outside brackets.

   ʿͤλȤäƤѥåץȤϡSubject: γѳ [] 
   Ϥޤ줿ʬ뤳Ȥդ뤳ȡѳ̤Τ
   ĹŪˤϤΥѥåȴطΤʤ褦ʾˤ٤Ǥ롣
   Ȥ "patch" ȤñϢ֤ʤɤǤ롣äƥ֥ƥ
    (嵭Ǥ ext2:) ϳѳ̤γ¦˽񤯤٤


3: Attribution
3: Ԥɽ
==============

If someone else wrote the patch, they should be credited (and blamed) for it. 
To communicate this, add a line:

⤷ï¾ͤѥå񤤤Τʤ顢οͤ쥸åȤ (񤵤)
褦ˤ٤ξ뤿ˤϡʲΤ褦ʰԤŻҥ᡼
ǽΰԤ˽񤭲ä뤳 -

From: John Doe <jdoe@wherever.com>

as the very first line of the email.  Downstream tools will pick this up and
jdoe will get the git "Author" line.

ήΥġ뤬򽦤jdoe  git (: ͥ륽ɴ
ġ̾)  "Author" Ԥɽ褦ˤʤ롣


4: Changelog
4: ѹ
============

a) Bear in mind that the Subject: and changelog which you provide will
   propagate all the way into the permanent kernel record.  Other developers
   will want to read and understand your patch and changelog years in the
   future.

   ʬν񤤤 Subject: ѹϡϤФ¤ͥ
   ȤƱʵפ˵Ͽ뤳Ȥ򿴤αƤȡ¾γȯԤ
   ǯˤʤΥѥåѹɤȤ򤷤褦Ȥ
   Ȥ

   So the changelog should describe the patch fully:

   ѹˤϤΥѥåˤĤưʲΤ褦ʻ
   ϳʤҤƤ٤ -

   - why the kernel needed patching
   - ͥ˥ѥåɬפͳ

   - the overall design approach in the patch
   - ѥåŪ߷ά

   - implementation details
   - ξܺ

   - testing results
   - ƥȤη


b) Don't bother mentioning what version of the kernel the patch applies to
   ("applies to 2.6.8-rc1").  This is not interesting information - once the
   patch is in the kernel.org kernel, of _course_ it applied, and it'll
   probably be merged into a later kernel than the one which you wrote it for.

   ѥåɤΥСŬѤǤΤ ("applies to 2.6.8-rc1"
   (2.6.8-rc1 ŬѤǤ)) ɬפϤʤ⤷ kernel.org ǥͥ
   ޤ줿ʤСŬѤǤΤ餯ϥѥå
   оݤȤƤСΥͥ˥ޡ
   Ǥ顢ɤΥСŬѤǤѥåʤΤѹ
   ǤϤޤפǤϤʤ

c) Don't include text such as "this patch does ..." or "here is patch which
   ...".  There's no point in telling us that it's a patch - once it's in the
   kernel SCM we _know_ it's a patch!

   "this patch does..." (֤ϡ򤹤ѥåǤ)
   "here is patch which..." (֤Υѥåϡ) Ȥäɽ
   ޤʤȡͥ SCM (: Source Code Management ά
   ʤ git Τ) äƤޤФϥѥåǤ뤳Ȥ
   ʤΤǥѥåǤ뤳Ȥ虜虜ͤϤʤ

d) Do not refer to earlier patches when changelogging a new version of a
   patch.  It's not very useful to have a final changelog which says "OK,
   this fixes the things you mentioned yesterday".  Each iteration of the
   patch should contain a standalone changelog.  This implies that you need a
   patch management system which maintains changelogs.  See below.

   ѥåοСѹǰΥѥåؤθڤ򤷤ʤȡ
   ǽŪѹˡOKŦ줿פȽ񤫤
   Ƥ⤢ޤ̣ʤѥåƤȤѹΩ
   ̣ʤ褦ˤ٤Ǥ롣
   ѹǤѥåƥबɬפˤʤ뤳Ȥ
   Ť˰̣Ƥ롣򻲾Ȥ衣

e) Add a Signed-off-by: line, as per section 11 of the
   Documentation/SubmittingPatches file in the kernel tree.

   ͥĥ꡼ Documentation/SubmittingPatches եι 11 
   褦ˡSigned-off-by: Ԥ񤯤ȡ

   Signed-off-by: implies that you had some part in the developent of the
   patch, or that you handled it and passed it on to another developer for
   merging.

   Signed-off-by: ԤϤοͤѥåȯΰʬôäꡢοͤ
   ؤä塢ޡΤ¾γȯԤϤꤷȤ̣롣

   If your role was purely review and/or testing, please use Acked-by:
   instead.

   ⤷̤䤬˥ӥ塼ƥȡ뤤Ϥξʤ
   Acked-by: ˻Ȥȡ

   Sometimes we also use Cc: in a patch to keep particular individuals
   abreast of the patch's status and to give them an opportunity to review it.

   ˤθĿͤ˥ѥåξȤȤ˥ӥ塼Ƥ餦
   褦ꤤ뤿ᡢCc: ȤȤ⤢롣

f) Most people's patch receiving scripts will treat a ^--- string as the
   separator between the changelog and the patch itself.  You can use this to
   ensure that any diffstat information is discarded when the patch is
   applied:

   ۤȤɤοͤΥѥå륹ץȤ ^--- (: ^ ɽ
   ƬɽƤ) ȤʸѹȥѥåΤΤδ֤
   ѥ졼ȤưѤƥѥåŬѻ diffstat 
   ΤƤ뤳ȤǤ롣

	Another few #if/#ifdef cleanups, this time for the PPC architecture.
        (ˤĤ #if/#ifdef ꡼󥢥åס PPC 
        ƥ)

	Signed-off-by: <valdis.kletnieks@vt.edu>
	Signed-off-by: Andrew Morton <akpm@osdl.org>
	---

	 25-akpm/arch/ppc/kernel/process.c                    |    2 +-
	 25-akpm/arch/ppc/platforms/85xx/mpc85xx_cds_common.c |    2 +-
	 25-akpm/arch/ppc/syslib/ppc85xx_setup.c              |    4 ++--
	 3 files changed, 4 insertions(+), 4 deletions(-)

	--- 25/arch/ppc/kernel/process.c
	+++ 25/arch/ppc/kernel/process.c
	@@ -667,7 +667,7 @@ void show_stack(struct task_struct *tsk,

g) Non-changelog text:

   ѹʳʸ -

   Sometimes you want to include text in the email which isn't designed to
   go into the changelog in the git repository.  Things like "this is already
   in Fred's tree" or "this is an updated version of last Friday's patch" or
   whatever.

   ˤ git ݥȥѹˤ줿ʤʸŻҥ᡼
   ޤ᤿Ȥ㤨С֤ Fred Υĥ꡼ˤǤ
   äƤס֤轵ˤΥѥåΥåץǡǤ

   You should place such text below the "^---" separator so that it is
   auto-removed when being placed into the revision control system.

   äʸ "^---" ѥ졼β֤ơӥ
   ƥδ֤ȤˤϼưŪ˺褦ˤ٤


5: The diff
5: ʬ
===========

a) Patches should be in `patch -p1' form:

   ѥåϰʲΤ褦 `patch -p1' ǼʤФʤ -

  --- a/kernel/sched.c
  +++ b/kernel/sched.c

b) Make sure that your patches apply to the latest version of the kernel
   tree.  Either straight from Linus's git tree or from
   ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/

   ѥåϺǿСΥͥĥ꡼ŬѤǤ褦ˤ뤳ȡ
   ľ Linus  git ĥ꡼ľܻäƤ뤫
   ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/ ꤹ뤳ȡ

c) When raising patches for -mm kernels it's generally best to base them on
   the latest Linus tree.  I'll work out any rejects/incompatibilities.  There
   are of course exceptions to this.

   ѥå -mm ͥФˤϰŪˤϺǿ
   Linus ĥ꡼ˤΤФɤꥸȤߴʬ
    (: Andrew Morton) ʤȤ롣󤳤ˤ㳰롣

d) Ensure that your patch does not add new trailing whitespace.  The below
   script will fix up your patch by stripping off such whitespace.

   ѥåǿ˹ζ䤹Ȥʤ褦ˡʲΥץȤϡ
   ääƥѥåƤ롣

	#!/bin/sh

	strip1()
	{
		TMP=$(mktemp /tmp/XXXXXX)
		cp "$1" "$TMP"
		sed -e '/^+/s/[ 	]*$//' <"$TMP" >"$1"
		rm "$TMP"
	}

	for i in "$@"
	do
		strip1 "$i"
	done


6: Patch series
6: ϢΥѥå
===============

a) When sending a series of patches, number them in the Subject:s thusly:

   ϢΥѥåƤϡSubject: ֹ򿶤äưʲΤ褦
   뤳 -

	[patch 1/10] ext2: block allocation: frob the globnozzle
	[patch 2/10] ext2: block allocation: wash the pizza
	etc.

	([patch 1/10] ext2: ֥å: Ĥ
	 [patch 2/10] ext2: ֥å: ԥ
         )

   (: frob the globnozzle/wash the pizza δްդϡ̣ä
    դ򤹤ȤȡʸȽ񤯤 (Τ褦ʤФ
    ʸǤϤʤ) ȤäȤΤ褦Ǥ)

b) Some people like to introduce a patch series with an introductory email
   which doesn't actually carry a patch, such as:

   ϢΥѥå˴ؤʪ뤿ᡢѥåޤޤʤ
   ʲΤ褦֤᡼򹥤ǻȤͤ -

	[patch 0/10] ext2: block allocation changes
	([patch 0/10] ext2: ֥åƤѹ)

   Please don't do this.  There is no facility in the git tree to carry
   changelog-only changesets such as this (or at least, we don't do that) so
   the information in the introductory email will be lost.

  ϤʤǤۤgit ĥ꡼ˤϤΤ褦ѹ
  󥸥åȤ򰷤ˡʤ (ʤȤ⡢桹ϤΤ褦ˤƤʤ)
  ΤǤξҲ᡼ξϼƤޤ

   So I end up copying and pasting your nice introduction into the
   changelog for the first patch, so it gets into git.  I'll follow it with
   the text

   Ϥ餷Ƴʬ git ˻Ĥ˺ǽΥѥå
   ѹ˥ԡ&ڡȤ뱩ܤˤʤ롣θ

	This patch:
	(Υѥåϡ)

   and then I'll include the changelog for the first patch of the series.

   ȤäϢΥѥåκǽʬѹ˷ҤΤ

   It would be preferred if the patch originators were to do this.

   ϥѥåκԤƤȹޤΤǰʤ
   ϤäƤʤ

c) Try very hard to ensure that the kernel builds and runs correctly at
   every step of the patch series.  This requirement exists because of
   `git-bisect'.  If someone is doing a bisection search for a kernel bug and
   they land upon your won't-compile point partway through the exercise, they
   will be unhappy.

   ȤˤϢΥѥåΤɤʳǤ⥫ͥӥɤȥͥư
   Ǥ뤳ȤݾڤƤۤ `git-bisect' ΤɬפʤΤ
   ⤷ïͥХĴΤʬõԤäƤ
   ïΤǥѥǤʤ褦ä鵤ʬ


d) If your patch series includes non-runtime-affecting things such as
   cleanups, whitespace fixes, file renames, moving functions around, etc. then
   this work should be done in the initial patches in the series.  The
   functional changes should come later in the series.

   ⤷ϢΥѥå˥꡼󥢥åפνե̾
   ѹؿΰưʤɼ¹Ի˱ƶΤʤΤޤǤΤʤ
   ϢΥѥåκǽǤ٤ǽŪѹϤθ٤

   This is mainly so that reversion of problematic changes becomes simpler.

   ϼȤ꤬Фѹʬ򸵤᤹Τñˤ뤿


7: Overall
7: Ūʻ
==========


a) Avoid MIME and attachements if possible.  Make sure that your email
   client does not wordwrap your patch.  Make sure that your email client does
   not replace tabs with spaces.

   MIME źդǤ򤱤뤳ȡ᡼륯饤Ȥѥå
   Ԥޤ֤ꤷʤ褦ˤ뤳ȡ᡼륯饤Ȥ
   ֤֤ʤ褦ˤ뤳ȡ

   Mail yourself a decent-sized patch and check that it still applies.

   ʬƤˤʤ礭ΥѥåäơŬѤǤ뤳Ȥ
   ǧ뤳ȡ

b) If all this still hopelessly fails then MIME attachments are an acceptable
   reluctant fallback.  You must ensure that the attached patches have
   text/plain mimetypes.

   ⤷餬ɤ⤳ɤƤ⤦ޤʤ硢MIME źդ
   ƵƲǽƨƻźդѥå MIMEפ text/plain 
   ʤФʤ

The patch management scripts at http://www.zip.com.au/~akpm/linux/patches/
implement all of the above.

http://www.zip.com.au/~akpm/linux/patches/ ˤѥåץȤ
嵭ƤƤ롣

The patch management tools at https://savannah.nongnu.org/projects/quilt/ also
implement all of the above.

https://savannah.nongnu.org/projects/quilt/ ˤѥåġ嵭Ƥ
Ƥ롣

Many example patches may be found under
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/

¿λͤȤʤѥåϰʲURL֤Ƥ롣
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
