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