diff options
Diffstat (limited to 'Documentation/development-process/5.Posting')
| -rw-r--r-- | Documentation/development-process/5.Posting | 26 |
1 files changed, 20 insertions, 6 deletions
diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index 8a48c9b62864..b511ddf7e82a 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting @@ -1,4 +1,7 @@ -5: POSTING PATCHES +.. _development_posting: + +Posting patches +=============== Sooner or later, the time comes when your work is ready to be presented to the community for review and, eventually, inclusion into the mainline @@ -11,7 +14,8 @@ SubmittingDrivers, and SubmitChecklist in the kernel documentation directory. -5.1: WHEN TO POST +When to post +------------ There is a constant temptation to avoid posting patches before they are completely "ready." For simple patches, that is not a problem. If the @@ -27,7 +31,8 @@ patches which are known to be half-baked, but those who do will come in with the idea that they can help you drive the work in the right direction. -5.2: BEFORE CREATING PATCHES +Before creating patches +----------------------- There are a number of things which should be done before you consider sending patches to the development community. These include: @@ -52,7 +57,8 @@ As a general rule, putting in some extra thought before posting code almost always pays back the effort in short order. -5.3: PATCH PREPARATION +Patch preparation +----------------- The preparation of patches for posting can be a surprising amount of work, but, once again, attempting to save time here is not generally advisable @@ -122,7 +128,8 @@ which takes quite a bit of time and thought after the "real work" has been done. When done properly, though, it is time well spent. -5.4: PATCH FORMATTING AND CHANGELOGS +Patch formatting and changelogs +------------------------------- So now you have a perfect series of patches for posting, but the work is not done quite yet. Each patch needs to be formatted into a message which @@ -140,6 +147,8 @@ that end, each patch will be composed of the following: subsystem name first, followed by the purpose of the patch. For example: + :: + gpio: fix build on CONFIG_GPIO_SYSFS=n - A blank line followed by a detailed description of the contents of the @@ -192,6 +201,8 @@ been associated with the development of this patch. They are described in detail in the SubmittingPatches document; what follows here is a brief summary. Each of these lines has the format: +:: + tag: Full Name <email address> optional-other-stuff The tags in common use are: @@ -225,7 +236,8 @@ Be careful in the addition of tags to your patches: only Cc: is appropriate for addition without the explicit permission of the person named. -5.5: SENDING THE PATCH +Sending the patch +----------------- Before you mail your patches, there are a couple of other things you should take care of: @@ -287,6 +299,8 @@ obvious maintainer, Andrew Morton is often the patch target of last resort. Patches need good subject lines. The canonical format for a patch line is something like: +:: + [PATCH nn/mm] subsys: one-line description of the patch where "nn" is the ordinal number of the patch, "mm" is the total number of |