public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Ben Minerds <puzzleduck@gmail.com>
Cc: greg@kroah.com, Ben Minerds <PuZZleDucK@gmail.com>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/8] Documentation: Replacing reference to broken submission format URL
Date: Thu, 23 May 2013 23:16:19 -0500	[thread overview]
Message-ID: <1369368979.2776.15@driftwood> (raw)
In-Reply-To: <b8531ed3e293a3dd41f5d62f02229c7dbf279a5a.1369312746.git.PuZZleDucK@gmail.com> (from puzzleduck@gmail.com on Thu May 23 07:49:57 2013)

On 05/23/2013 07:49:57 AM, Ben Minerds wrote:
>  Replacing refs to broken URL with internal documentation reference,  
> and a
>  little whitespace shuffle to keep it under 80 chars wide.
> 
>  Signed-off-by: Ben Minerds <puzzleduck@gmail.com>
> ---
>  Documentation/HOWTO                   | 10 +++++-----
>  Documentation/SubmittingPatches       |  2 +-
>  Documentation/ja_JP/HOWTO             |  8 ++++----
>  Documentation/ja_JP/SubmittingPatches |  2 +-
>  Documentation/ko_KR/HOWTO             |  2 +-
>  Documentation/zh_CN/HOWTO             |  2 +-
>  Documentation/zh_CN/SubmittingPatches |  2 +-
>  7 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/Documentation/HOWTO b/Documentation/HOWTO
> index 11e597e..fba34c0 100644
> --- a/Documentation/HOWTO
> +++ b/Documentation/HOWTO
> @@ -110,11 +110,11 @@ required reading:
>      subject to scrutiny for content and style), but not following  
> them
>      will almost always prevent it.
> 
> -    Other excellent descriptions of how to create patches properly  
> are:
> -	"The Perfect Patch"
> -		 
> Documentation/development-process/patches/The-Perfect-Patch.txt
> -	"Linux kernel patch submission format"
> -		http://linux.yyz.us/patch-format.html
> +  Other excellent descriptions of how to create patches properly are:
> +    "The Perfect Patch"
> +      Documentation/development-process/patches/The-Perfect-Patch.txt
> +    "Linux kernel patch submission format"
> +       
> Documentation/development-process/patches/Patch-Submission-Format.txt

Ok, this is the third consecutive patch to do approximately the same  
thing, and now you're patching lines you added in a previous patch in  
the same series.

Breaking files up into stages helps with bisectability. Are we really  
going to "git bisect" documentation?

On the larger question of "is this a good idea", I'm leaning towards  
"no" and would like you to explain why an 8 year old description  
duplicating portions of SubmittingPatches needs to be in-tree.

Rob

  reply	other threads:[~2013-05-24  4:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-23 12:49 [PATCH 0/8] Documentation: Updating docs and links relating to patches Ben Minerds
2013-05-23 12:49 ` [PATCH 1/8] Documentation: Adding "The Perfect Patch" by Andrew Morton Ben Minerds
2013-05-23 17:15   ` Dave Jones
2013-05-24  4:10   ` Rob Landley
2013-05-24  4:16     ` Joe Perches
2013-05-23 12:49 ` [PATCH 2/8] Documentation: Adding "Linux Kernel Patch Submission Format" Ben Minerds
2013-05-24  4:12   ` Rob Landley
2013-05-23 12:49 ` [PATCH 3/8] Documentation: Replacing references to broken perfect patch URL Ben Minerds
2013-05-23 12:49 ` [PATCH 4/8] Documentation: Replacing reference " Ben Minerds
2013-05-23 12:49 ` [PATCH 5/8] Documentation: Replacing reference to broken submission format URL Ben Minerds
2013-05-24  4:16   ` Rob Landley [this message]
2013-05-23 12:49 ` [PATCH 6/8] Documentation: Updating a broken link in "the perfect patch" Ben Minerds
2013-05-24  4:21   ` Rob Landley
2013-05-23 12:49 ` [PATCH 7/8] Documentation: Reformatting "Linux Kernel Patch Submission Format" Ben Minerds
2013-05-23 12:50 ` [PATCH 8/8] Documentation: Move other patch related document Ben Minerds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1369368979.2776.15@driftwood \
    --to=rob@landley.net \
    --cc=greg@kroah.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=puzzleduck@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox