1 From: Mark Brown <broonie@opensource.wolfsonmicro.com>
2 Subject: Re: rfc: rewrite commit subject line for subsystem
3 maintainer preference tool
4 Date: Wed, 17 Nov 2010 17:07:47 +0000
6 Message-ID: <20101117170746.GB19488@rakim.wolfsonmicro.main>
7 References: <20101116104921.GL12986@rakim.wolfsonmicro.main>
8 <1289919077.28741.50.camel@Joe-Laptop>
9 <20101116183707.179964dd@schatten.dmk.lab>
10 <20101116181226.GB26239@rakim.wolfsonmicro.main>
11 <20101116203522.65240b18@schatten.dmk.lab>
12 <20101116195530.GA7523@rakim.wolfsonmicro.main>
13 <20101116122102.86e7e0b9.rdunlap@xenotime.net>
14 <20101116230126.GB24623@opensource.wolfsonmicro.com>
15 <20101117014427.41d85b13@stein>
16 <alpine.LNX.2.00.1011170150060.7420@pobox.suse.cz>
18 Content-Type: text/plain; charset="us-ascii"
19 Content-Transfer-Encoding: 7bit
20 Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
21 Florian Mickler <florian@mickler.org>, Randy Dunlap <rdunlap@xenotime.net>,
22 Stefan Richter <stefanr@s5r6.in-berlin.de>, Joe Perches <joe@perches.com>,
23 Andrew Morton <akpm@linux-foundation.org>
24 To: Jiri Kosina <jkosina@suse.cz>
25 X-From: alsa-devel-bounces@alsa-project.org Wed Nov 17 18:07:59 2010
26 Return-path: <alsa-devel-bounces@alsa-project.org>
27 Envelope-to: glad-alsa-devel-2@m.gmane.org
28 Received: from alsa0.perex.cz ([212.20.107.51])
29 by lo.gmane.org with esmtp (Exim 4.69)
30 (envelope-from <alsa-devel-bounces@alsa-project.org>)
32 for glad-alsa-devel-2@m.gmane.org; Wed, 17 Nov 2010 18:07:57 +0100
33 Received: by alsa0.perex.cz (Postfix, from userid 1000)
34 id B1000245CE; Wed, 17 Nov 2010 18:07:54 +0100 (CET)
35 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mail1.perex.cz
37 X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled
39 Received: from alsa0.perex.cz (localhost [127.0.0.1])
40 by alsa0.perex.cz (Postfix) with ESMTP id C35471037EC;
41 Wed, 17 Nov 2010 18:07:52 +0100 (CET)
42 X-Original-To: alsa-devel@alsa-project.org
43 Delivered-To: alsa-devel@alsa-project.org
44 Received: by alsa0.perex.cz (Postfix, from userid 1000)
45 id 4EE8F1037EC; Wed, 17 Nov 2010 18:07:51 +0100 (CET)
46 Received: from opensource2.wolfsonmicro.com (opensource.wolfsonmicro.com
47 [80.75.67.52]) by alsa0.perex.cz (Postfix) with ESMTP id A8A16245CE
48 for <alsa-devel@alsa-project.org>; Wed, 17 Nov 2010 18:07:50 +0100 (CET)
49 Received: from rakim.wolfsonmicro.main (lumison.wolfsonmicro.com
51 by opensource2.wolfsonmicro.com (Postfix) with ESMTPSA id 9E3591147AC;
52 Wed, 17 Nov 2010 17:07:48 +0000 (GMT)
53 Received: from broonie by rakim.wolfsonmicro.main with local (Exim 4.72)
54 (envelope-from <broonie@rakim.wolfsonmicro.main>)
55 id 1PIlU3-00061C-Bl; Wed, 17 Nov 2010 17:07:47 +0000
56 Content-Disposition: inline
57 In-Reply-To: <alpine.LNX.2.00.1011170150060.7420@pobox.suse.cz>
58 X-Cookie: Killing turkeys causes winter.
59 User-Agent: Mutt/1.5.20 (2009-06-14)
60 X-BeenThere: alsa-devel@alsa-project.org
61 X-Mailman-Version: 2.1.9
63 List-Id: "Alsa-devel mailing list for ALSA developers -
64 http://www.alsa-project.org" <alsa-devel.alsa-project.org>
65 List-Unsubscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
66 <mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
67 List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel>
68 List-Post: <mailto:alsa-devel@alsa-project.org>
69 List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
70 List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
71 <mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
72 Sender: alsa-devel-bounces@alsa-project.org
73 Errors-To: alsa-devel-bounces@alsa-project.org
74 Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1064007>
76 On Wed, Nov 17, 2010 at 01:53:35AM +0100, Jiri Kosina wrote:
77 > On Wed, 17 Nov 2010, Stefan Richter wrote:
79 > > Why should we codify our conventions in MAINTAINERS to accommodate the
80 > > specific problem of virtually a _single_ patch author?
82 It seems to be the way we're heading in general - look at all the recent
83 work on MAINTAINERS and get_maintainer.pl. There seems to be a genral
84 push to make all this stuff automatable.
86 > Either the maintainer wants the patch. Then he is certainly able to apply
87 > it no matter the subject line (I personally am getting a lot of patches
88 > which don't follow the format I am using in my tree ... converting
89 > Subject: lines is so trivial that I have never felt like bothering anyone
90 > about it ... it's basically single condition in a shellscript). Or the
92 It's slightly more than that if you're dealing with more than one area,
93 and I also find this sort of stuff is a good flag for scrubbing the
94 patch in greater detail - when patches stand out from a 1000ft visual
95 overview there's a fair chance that there's other issues so if people
96 regularly submit good patches that have only cosmetic issues I find it's
97 worth guiding them away from that.
99 > maintainer doesn't feel like the patch is worth it, and then the
100 > subject-line format really doesn't matter.
102 In this case if I don't apply it it's likely to end up going in via your
103 tree and then I'll still have to deal with the merge conflicts which are