From: Randy Dunlap <rdunlap@xenotime.net>
To: Richard Hartmann <richih.mailinglist@gmail.com>
Cc: linux-crypto@vger.kernel.org, Andy Whitcroft <apw@canonical.com>,
Andrew Morton <akpm@linux-foundation.org>,
Daniel Walker <dwalker@fifo99.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] SCRIPTS: s/should/must/ for all ERRORs
Date: Wed, 10 Feb 2010 21:22:00 -0800 [thread overview]
Message-ID: <20100210212200.1e83b7c5.rdunlap@xenotime.net> (raw)
In-Reply-To: <2d460de71002100959j49c25e37n11a8870454251d84@mail.gmail.com>
On Wed, 10 Feb 2010 18:59:11 +0100 Richard Hartmann wrote:
> PS: As I am new to the whole concept of touching the large scary kernel
> let me use this opportunity to ask if I should expect answers on the
> other patch emails or if they are just merged zsh-style: Silently and
> you will notice what went through when you pull a few days later.
OK, since nobody else has tried to answer this, I'll give it a shot.
It happens many different ways in linux-kernel land, mostly depending on
who is doing the merging, and it's really up to the subsystem or driver
maintainer.
If Andrew Morton merges a patch into his mmotm patchset, you'll get an email
confirmation of it, but this just means that it's in the mmotm patches for
testing, not necessarily for merging into the mainline kernel tree.
If you send a networking patch and David S. Miller merges it, you will get
both an acknowledgement of that and you can see the patch's status at
http://patchwork.ozlabs.org/project/netdev/list/
Same for multimedia driver patches, but view their status at
http://patchwork.kernel.org/project/linux-media/list/
I don't recall if Andy Whitcroft acks checkpatch patches or not, but
you should note that checkpatch is not his highest priority job
(but I'm not trying to speak for him).
If you send patches for the staging or USB or stable pr serial/tty trees,
GregKH will usually ack them when they are merged.
If you send patches for ATA drivers, Jeff Garzik will usually ack them when
they are merged.
If you send patches for the SCSI drivers/subsystem, good luck, the SCSI
mailing list is the best place to find out their status.
If you send patches for parts of Documentation/ that are obviously not
cared for by someone else, I'll try to get to them, but that's not my
highest priority either. I will ack them if/when I merge them.
I guess if it's not clear to you or anyone else, most Linux maintainers
also have other jobs that they usually need to do...
HTH. If you have specific questions, ask away, or maybe Andy can tell us
about checkpatch patches.
---
~Randy
next prev parent reply other threads:[~2010-02-11 5:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-10 0:41 [PATCH 2/3] SCRIPTS: s/should/must/ for all ERRORs Richard Hartmann
2010-02-10 16:49 ` Randy Dunlap
2010-02-10 17:59 ` Richard Hartmann
2010-02-11 5:22 ` Randy Dunlap [this message]
2010-02-11 7:04 ` Richard Hartmann
2010-02-11 22:01 ` Krzysztof Halasa
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=20100210212200.1e83b7c5.rdunlap@xenotime.net \
--to=rdunlap@xenotime.net \
--cc=akpm@linux-foundation.org \
--cc=apw@canonical.com \
--cc=dwalker@fifo99.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richih.mailinglist@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