From: Ingo Molnar <mingo@elte.hu>
To: Jack Stone <jwjstone@fastmail.fm>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Cc: Bert Wesarg <bert.wesarg@googlemail.com>,
linux-kernel@vger.kernel.org, jeff@garzik.org,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH 54/56] x86: Remove void casts
Date: Wed, 8 Apr 2009 17:16:44 +0200 [thread overview]
Message-ID: <20090408151644.GQ12931@elte.hu> (raw)
In-Reply-To: <49DCBBDF.4040603@fastmail.fm>
* Jack Stone <jwjstone@fastmail.fm> wrote:
> Ingo Molnar wrote:
>
> > Since you do many such patches it might make sense to script up
> > a "who maintains what" kind of script - and share that script
> > with lkml.
> >
> > I have this silly little script:
> >
> > git log $@ | grep Signed-off-by: |
> > cut -d: -f2 | cut -d\< -f1 |
> > sort | uniq -c | sort -n
> >
> > To find out any recent parties that touches a particular file.
> > But it would be nice to somehow automate the pickup of
> > mailing-list addresses from MAINTAINERS for example. We've
> > literally got hundreds of email lists there.
> >
> > It is not trivial to do though :-)
>
> It would be useful. The main problem is working out what files
> belong to what MAINTAINERS entries.
>
> I'll see what I can cook up.
In theory we could put regex patterns into MAINTAINERS. Something
like this:
LOCKDEP AND LOCKSTAT
P: Peter Zijlstra
M: peterz@infradead.org
P: Ingo Molnar
M: mingo@redhat.com
L: linux-kernel@vger.kernel.org
T: git://git.kernel.org/pub/scm/linux/kernel/git/peterz/linux-2.6-lockdep.git
F: kernel/lock*
F: include/linux/lockdep.h
S: Maintained
Note: there are files that fall under multiple maintainers so this
wouldnt be a 'precise' thing - but it would sure be useful.
( There's also other details like subdirectories within a larger
hiearchy and there being overlap between problems. Sometimes they
are sub-maintained, sometimes they are exclusive so pure glob
patterns are probably not enough. )
If this concept looks good to you ... i'd suggest that before you do
a large patch against MAINTAINERS mapping all the maintainer
domains, could you just do it for a few cases and send an RFC patch
to lkml?
If there's a general upstream buy-in and a there's a
scripts/list-maintainers.sh script that takes advantage of it then
all this would be rather useful. (and i've Cc:-ed Andrew and Linus -
if this is to be shot down due to fundamental objections then better
do it at the early stages ;-)
Plus checkpatch could be extended to check whether the Cc: list in a
patch properly matches the patterns in MAINTAINERS.
If done propery this would save us from quite a few mechanic "hm,
who maintains _that_ file??" searches and it would also save
maintainers from quite a few "hm, who queued up _that_ crap without
Cc:-ing me??" moments.
Thanks,
Ingo
next prev parent reply other threads:[~2009-04-08 15:18 UTC|newest]
Thread overview: 174+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 11:21 [PATCH 0/56] Remove void casts Jack Stone
2009-04-08 11:21 ` [PATCH 01/56] adfs: " Jack Stone
2009-04-08 11:21 ` [PATCH 02/56] alpha: " Jack Stone
2009-04-08 11:21 ` [PATCH 03/56] atm: " Jack Stone
2009-04-08 11:21 ` [PATCH 04/56] befs: " Jack Stone
2009-04-08 11:21 ` [PATCH 05/56] block: " Jack Stone
2009-04-08 11:21 ` [PATCH 06/56] cifs: " Jack Stone
2009-04-08 11:21 ` [PATCH 07/56] coda: " Jack Stone
2009-04-08 11:21 ` [PATCH 08/56] cris: " Jack Stone
2009-04-08 11:21 ` [PATCH 09/56] efs: " Jack Stone
2009-04-08 11:21 ` [PATCH 10/56] ext2: " Jack Stone
2009-04-08 11:21 ` [PATCH 11/56] freevxfs: " Jack Stone
2009-04-08 11:21 ` [PATCH 12/56] hpfs: " Jack Stone
2009-04-08 11:21 ` [PATCH 13/56] i2c: " Jack Stone
2009-04-08 11:21 ` [PATCH 14/56] ia64: " Jack Stone
2009-04-08 11:21 ` [PATCH 15/56] ide: " Jack Stone
2009-04-08 11:21 ` [PATCH 16/56] idle: " Jack Stone
2009-04-08 11:21 ` [PATCH 17/56] infiniband: " Jack Stone
2009-04-08 11:21 ` [PATCH 18/56] isdn: " Jack Stone
2009-04-08 11:21 ` [PATCH 19/56] kvm: " Jack Stone
2009-04-08 11:21 ` [PATCH 20/56] inflate: " Jack Stone
2009-04-08 11:21 ` [PATCH 21/56] md: " Jack Stone
2009-04-08 11:21 ` [PATCH 22/56] message/fusion: " Jack Stone
2009-04-08 11:21 ` [PATCH 23/56] minix: " Jack Stone
2009-04-08 11:21 ` [PATCH 24/56] mips: " Jack Stone
2009-04-08 11:21 ` [PATCH 25/56] mm: " Jack Stone
2009-04-08 11:21 ` [PATCH 26/56] ncpfs: " Jack Stone
2009-04-08 11:21 ` [PATCH 27/56] ipv4: " Jack Stone
2009-04-08 11:22 ` [PATCH 28/56] ipv6: " Jack Stone
2009-04-08 11:22 ` [PATCH 29/56] irda: " Jack Stone
2009-04-08 11:22 ` [PATCH 30/56] net: " Jack Stone
2009-04-08 11:22 ` [PATCH 31/56] sctp: " Jack Stone
2009-04-08 11:22 ` [PATCH 32/56] sunrpc: " Jack Stone
2009-04-08 11:22 ` [PATCH 33/56] tipc: " Jack Stone
2009-04-08 11:22 ` [PATCH 34/56] nfs: " Jack Stone
2009-04-08 11:22 ` [PATCH 35/56] ntfs: " Jack Stone
2009-04-08 11:22 ` [PATCH 36/56] ocfs2: " Jack Stone
2009-04-08 11:22 ` [PATCH 37/56] oss: " Jack Stone
2009-04-08 11:22 ` [PATCH 38/56] pci: " Jack Stone
2009-04-08 11:22 ` [PATCH 39/56] powerpc: " Jack Stone
2009-04-08 11:22 ` [PATCH 40/56] proc: " Jack Stone
2009-04-08 11:22 ` [PATCH 41/56] reiserfs: " Jack Stone
2009-04-08 11:22 ` [PATCH 42/56] drivers/s390: " Jack Stone
2009-04-08 11:22 ` [PATCH 43/56] s390: " Jack Stone
2009-04-08 11:22 ` [PATCH 44/56] scripts: " Jack Stone
2009-04-08 11:22 ` [PATCH 45/56] scsi: " Jack Stone
2009-04-08 11:22 ` [PATCH 46/56] serial: " Jack Stone
2009-04-08 11:22 ` [PATCH 47/56] sh: " Jack Stone
2009-04-08 11:22 ` [PATCH 48/56] smbfs: " Jack Stone
2009-04-08 11:22 ` [PATCH 49/56] sparc: " Jack Stone
2009-04-08 11:22 ` [PATCH 50/56] drivers/staging: " Jack Stone
2009-04-08 11:22 ` [PATCH 51/56] sysv: " Jack Stone
2009-04-08 11:22 ` [PATCH 52/56] ufs: " Jack Stone
2009-04-08 11:22 ` [PATCH 53/56] usb: " Jack Stone
2009-04-08 11:22 ` [PATCH 54/56] x86: " Jack Stone
2009-04-08 11:22 ` [PATCH 55/56] xen: " Jack Stone
2009-04-08 11:22 ` [PATCH 56/56] xfs: " Jack Stone
2009-04-08 12:15 ` Bert Wesarg
2009-04-08 14:01 ` Jack Stone
2009-04-09 10:39 ` Jack Stone
2009-04-09 17:37 ` Felix Blyakher
2009-04-13 9:32 ` Christoph Hellwig
2009-04-13 9:35 ` Jeff Garzik
2009-04-09 10:39 ` [PATCH 55/56] xen: " Jack Stone
2009-04-09 18:15 ` Jeremy Fitzhardinge
2009-04-08 12:18 ` [PATCH 54/56] x86: " Bert Wesarg
2009-04-08 14:03 ` Jack Stone
2009-04-08 14:06 ` Ingo Molnar
2009-04-08 14:14 ` Jack Stone
2009-04-08 14:40 ` Ingo Molnar
2009-04-08 14:46 ` Jack Stone
2009-04-08 14:48 ` Ingo Molnar
2009-04-08 14:53 ` Jack Stone
2009-04-08 14:57 ` Ingo Molnar
2009-04-08 14:59 ` Jack Stone
2009-04-08 15:05 ` Jack Stone
2009-04-08 15:06 ` Julia Lawall
2009-04-08 15:10 ` Matthew Wilcox
2009-04-08 15:12 ` Julia Lawall
2009-04-08 15:16 ` Ingo Molnar [this message]
2009-04-08 20:45 ` Jack Stone
2009-04-08 22:06 ` Joe Perches
2009-04-09 5:12 ` Ingo Molnar
2009-04-09 10:37 ` Jack Stone
2009-04-08 12:11 ` [PATCH 53/56] usb: " Bert Wesarg
2009-04-08 14:00 ` Jack Stone
2009-04-09 10:36 ` Jack Stone
2009-04-09 10:35 ` [PATCH 52/56] ufs: " Jack Stone
2009-04-08 12:02 ` [PATCH 51/56] sysv: " Bert Wesarg
2009-04-08 12:04 ` Bert Wesarg
2009-04-08 12:07 ` Jack Stone
2009-04-08 13:57 ` Jack Stone
2009-04-09 10:34 ` Jack Stone
2009-04-08 12:09 ` [PATCH 50/56] drivers/staging: " Bert Wesarg
2009-04-08 13:59 ` Jack Stone
2009-04-09 10:32 ` Jack Stone
2009-04-09 10:31 ` [PATCH 49/56] sparc: " Jack Stone
2009-04-08 11:58 ` [PATCH 45/56] scsi: " Bert Wesarg
2009-04-08 13:56 ` Jack Stone
2009-04-09 10:27 ` Jack Stone
2009-04-09 10:26 ` [PATCH 43/56] s390: " Jack Stone
2009-04-09 10:23 ` [PATCH 42/56] drivers/s390: " Jack Stone
2009-04-09 10:22 ` [PATCH 41/56] reiserfs: " Jack Stone
2009-04-09 10:20 ` [PATCH 39/56] powerpc: " Jack Stone
2009-04-09 10:19 ` [PATCH 38/56] pci: " Jack Stone
2009-04-09 10:18 ` [PATCH 37/56] oss: " Jack Stone
2009-04-08 12:19 ` [PATCH 36/56] ocfs2: " Bert Wesarg
2009-04-08 14:04 ` Jack Stone
2009-04-09 10:16 ` Jack Stone
2009-04-08 12:22 ` [PATCH 35/56] ntfs: " Bert Wesarg
2009-04-08 14:04 ` Jack Stone
2009-04-09 10:15 ` Jack Stone
2009-04-09 10:14 ` [PATCH 34/56] nfs: " Jack Stone
2009-04-09 10:13 ` [PATCH 33/56] tipc: " Jack Stone
2009-04-09 10:12 ` [PATCH 32/56] sunrpc: " Jack Stone
2009-04-09 10:11 ` [PATCH 31/56] sctp: " Jack Stone
2009-04-08 12:30 ` [PATCH 30/56] net: " Bert Wesarg
2009-04-08 14:05 ` Jack Stone
2009-04-09 10:10 ` Jack Stone
2009-04-08 12:31 ` [PATCH 29/56] irda: " Bert Wesarg
2009-04-08 14:06 ` Jack Stone
2009-04-09 10:09 ` Jack Stone
2009-04-09 10:08 ` [PATCH 28/56] ipv6: " Jack Stone
2009-04-09 10:08 ` [PATCH 27/56] ipv4: " Jack Stone
2009-04-09 10:07 ` [PATCH 26/56] ncpfs: " Jack Stone
2009-04-09 10:06 ` [PATCH 25/56] mm: " Jack Stone
2009-04-09 10:05 ` [PATCH 24/56] mips: " Jack Stone
2009-04-08 11:43 ` [PATCH 22/56] message/fusion: " Bert Wesarg
2009-04-08 13:55 ` Jack Stone
2009-04-09 10:03 ` [PATCH 21/56] md: " Jack Stone
2009-04-08 11:39 ` [PATCH 20/56] inflate: " Bert Wesarg
2009-04-08 13:54 ` Jack Stone
2009-04-08 14:05 ` Will Newton
2009-04-08 14:12 ` Jack Stone
2009-04-08 14:18 ` Will Newton
2009-04-08 14:19 ` walter harms
2009-04-08 14:27 ` Jack Stone
2009-04-09 10:00 ` [PATCH 19/56] kvm: " Jack Stone
2009-04-08 11:37 ` [PATCH 18/56] isdn: " Bert Wesarg
2009-04-08 13:53 ` Jack Stone
2009-04-09 9:58 ` Jack Stone
2009-04-08 17:48 ` [PATCH 17/56] infiniband: " Roland Dreier
2009-04-09 9:57 ` [PATCH 15/56] ide: " Jack Stone
2009-04-16 19:09 ` Bartlomiej Zolnierkiewicz
2009-04-09 9:56 ` [PATCH 14/56] ia64: " Jack Stone
2009-04-09 9:55 ` [PATCH 13/56] i2c: " Jack Stone
2009-04-09 12:43 ` Jean Delvare
2009-04-09 12:51 ` Alan Cox
2009-04-09 14:52 ` Jean Delvare
2009-04-09 9:54 ` [PATCH 12/56] hpfs: " Jack Stone
2009-04-09 9:53 ` [PATCH 11/56] freevxfs: " Jack Stone
2009-04-09 9:52 ` [PATCH 10/56] ext2: " Jack Stone
2009-04-08 12:34 ` [PATCH 08/56] cris: " Bert Wesarg
2009-04-08 13:36 ` Jesper Nilsson
2009-04-08 13:38 ` Jack Stone
2009-04-08 12:35 ` Jesper Nilsson
2009-04-08 13:36 ` Jack Stone
2009-04-09 9:49 ` Jack Stone
2009-04-09 9:47 ` Jack Stone
2009-04-09 9:45 ` [PATCH 07/56] coda: " Jack Stone
2009-04-08 11:26 ` [PATCH 06/56] cifs: " Bert Wesarg
2009-04-08 13:51 ` Jack Stone
2009-04-09 9:51 ` Jack Stone
2009-04-09 9:44 ` Jack Stone
2009-04-08 11:31 ` [PATCH 05/56] block: " Bert Wesarg
2009-04-08 11:38 ` Jack Stone
2009-04-08 11:48 ` Bert Wesarg
2009-04-09 21:08 ` Al Viro
2009-04-09 9:43 ` Jack Stone
2009-04-08 11:26 ` [PATCH 04/56] befs: " Bert Wesarg
2009-04-08 13:49 ` Jack Stone
2009-04-09 9:39 ` Jack Stone
2009-04-09 9:42 ` [PATCH 03/56] atm: " Jack Stone
2009-04-09 9:41 ` [PATCH 02/56] alpha: " Jack Stone
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=20090408151644.GQ12931@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=bert.wesarg@googlemail.com \
--cc=jeff@garzik.org \
--cc=jwjstone@fastmail.fm \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/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;
as well as URLs for NNTP newsgroup(s).