1From: Florian Mickler <florian@mickler.org>
2Subject: Re: rfc: rewrite commit subject line for subsystem maintainer
3 preference tool
4Date: Tue, 16 Nov 2010 20:35:22 +0100
5Lines: 37
6Message-ID: <20101116203522.65240b18@schatten.dmk.lab>
7References: <1289842444.16461.140.camel@Joe-Laptop>
8	<20101115182708.GJ12986@rakim.wolfsonmicro.main>
9	<1289845830.16461.149.camel@Joe-Laptop>
10	<20101115190738.GF3338@sirena.org.uk>
11	<1289848458.16461.150.camel@Joe-Laptop>
12	<20101115193407.GK12986@rakim.wolfsonmicro.main>
13	<1289850773.16461.166.camel@Joe-Laptop>
14	<20101116104921.GL12986@rakim.wolfsonmicro.main>
15	<1289919077.28741.50.camel@Joe-Laptop>
16	<20101116183707.179964dd@schatten.dmk.lab>
17	<20101116181226.GB26239@rakim.wolfsonmicro.main>
18Mime-Version: 1.0
19Content-Type: text/plain; charset=US-ASCII
20Content-Transfer-Encoding: 7bit
21Cc: Joe Perches <joe@perches.com>, Jiri Kosina <trivial@kernel.org>,
22	Andrew Morton <akpm@linux-foundation.org>,
23	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
24To: Mark Brown <broonie@opensource.wolfsonmicro.com>
25X-From: linux-kernel-owner@vger.kernel.org Tue Nov 16 20:36:24 2010
26Return-path: <linux-kernel-owner@vger.kernel.org>
27Envelope-to: glk-linux-kernel-3@lo.gmane.org
28Received: from vger.kernel.org ([209.132.180.67])
29	by lo.gmane.org with esmtp (Exim 4.69)
30	(envelope-from <linux-kernel-owner@vger.kernel.org>)
31	id 1PIRKK-0004cK-An
32	for glk-linux-kernel-3@lo.gmane.org; Tue, 16 Nov 2010 20:36:24 +0100
33Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
34	id S932105Ab0KPTfy (ORCPT <rfc822;glk-linux-kernel-3@m.gmane.org>);
35	Tue, 16 Nov 2010 14:35:54 -0500
36Received: from ist.d-labs.de ([213.239.218.44]:46199 "EHLO mx01.d-labs.de"
37	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
38	id S1756324Ab0KPTfw (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
39	Tue, 16 Nov 2010 14:35:52 -0500
40Received: from schatten.dmk.lab (f053209081.adsl.alicedsl.de [78.53.209.81])
41	by mx01.d-labs.de (Postfix) with ESMTPSA id 8CEAA7FAFE;
42	Tue, 16 Nov 2010 20:35:09 +0100 (CET)
43In-Reply-To: <20101116181226.GB26239@rakim.wolfsonmicro.main>
44X-Mailer: Claws Mail 3.7.6cvs31 (GTK+ 2.20.1; x86_64-unknown-linux-gnu)
45Sender: linux-kernel-owner@vger.kernel.org
46Precedence: bulk
47List-ID: <linux-kernel.vger.kernel.org>
48X-Mailing-List: linux-kernel@vger.kernel.org
49Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1063309>
50
51On Tue, 16 Nov 2010 18:12:27 +0000
52Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
53
54> On Tue, Nov 16, 2010 at 06:37:07PM +0100, Florian Mickler wrote:
55>
56> > My first reaction to this is, it's silly. Certainly a
57> > subsystem-maintainer is capable of hacking something together that
58> > suits his needs or may just use a good editor to get the job done.
59> > After all, he might want to edit the commit message anyway. Also he has
60> > to have his act together for all non-conforming submitters anyway,
61> > because shurely, telling people to re-edit their patches subject line
62> > is not what one would consider "welcoming to newbies",  or whatever it
63> > is kernel subsystem maintainers have to be nowadays *g*...
64>
65> So, my general policy on this is that I tend to push back on patches
66> which don't just work with the toolset (subject lines are just one part
67> of it) to a variable extent depending on who's submitting and what
68> they're submitting.  One of the factors is that the more patches are
69> coming from someone the easier I expect their patches to be to work
70> with.
71>
72> The reason this came up is that this is one of the issues with Joe's
73> patches (which are rather frequent) but he is only willing to do things
74> that he can automate.
75
76Hehe, I know that I wouldn't want to hand edit every autogenerated patch
77people throw at me... What about just dropping everything before the
78last "]" or ":" and putting an autogenerated prefix before it in a
79pre-commit hook on your side?
80
81That should work most of the time... don't know... maybe other
82subsystem maintainers have some more suggestions on reducing the
83workload... this could even be an interesting topic for some summit...
84
85Regards,
86Flo
87
88
89
90