From: "Riley Williams" <Riley@Williams.Name>
To: "Bryan Whitehead" <driver@megahappy.net>
Cc: "Linux Kernel Development" <Linux-Kernel@Vger.Kernel.Org>
Subject: Re: [PATCH 2.6.2] Documentation/SubmittingPatches
Date: Thu, 5 Feb 2004 08:18:32 -0000 [thread overview]
Message-ID: <BKEGKPICNAKILKJKMHCAOEMFIIAA.Riley@Williams.Name> (raw)
In-Reply-To: <20040205072303.BCF79FA5F1@mrhankey.megahappy.net>
Hi Bryan.
> I've been trying to get my feet wet by submitting trivial
> patches to various maintainers and the responses have been,
> "you're not submitting you patches correctly". It seems most
> developers/maintainers want a diff done like this:
>
> cd /source-tree
> diff -u linux-2.6.2/FileToPatch.orig linux-2.6.2/FileToPatch
>
> instead of the "SubmitingPatches" document way:
>
> cd /source-tree/linux-2.6.2
> diff -u FileToPatch.orig FileToPatch
>
> It would be _great_ if the Documentation was more accurate to
> the taste of developers/maintainers...
Obviously, I can't speak for the rest of the developers, but my
personal stance has always been this: If I can identify both the
kernel version the patch is against and where in the source tree
is being patched, I will apply the patch. If not, I won't.
I suspect the change you note is due to the number of people who
submit patches within a directory in the source tree that don't
indicate either of the above facts. If the answers aren't obvious
from the email, I run `find -name ${FILE}` from the root directory
of the current source tree and if there's not more than three
possibilities for the file, I will try patching each of them to
see whether the patch will apply to any of them. Beyond that, I
want further information from the submitter.
One other thing I've found useful is to increase the context given
in the diff by using -u5 rather than just -u as that considerably
increases the chances of a successful patch when other patches have
already been applied. However, that's very much personal preference
and probably not shared by other developers.
As an example, if somebody sends me a patch that tweaks a file
called Makefile with no indication of either of the above - well,
let's just say I've better things to do with my time than to
search through the various files of that name in the various
kernel source trees to identify the correct one...
Best wishes from Riley.
---
* Nothing as pretty as a smile, nothing as ugly as a frown.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 30-Jan-2004
next prev parent reply other threads:[~2004-02-05 8:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-05 7:23 Bryan Whitehead
2004-02-05 8:18 ` Riley Williams [this message]
2004-02-05 19:05 ` Arthur Othieno
2004-02-06 3:45 ` jw schultz
2004-02-06 4:13 ` Randy.Dunlap
2004-02-06 17:23 ` Tim Bird
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=BKEGKPICNAKILKJKMHCAOEMFIIAA.Riley@Williams.Name \
--to=riley@williams.name \
--cc=Linux-Kernel@Vger.Kernel.Org \
--cc=driver@megahappy.net \
/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
all inboxes | Powered by JetHome®