notmuch/test/corpora/lkml/cur/1382298793.003278:2,
David Bremner e08f5f76e4 test: add 'lkml' corpus
These 210 messages are in several long threads, which is good for
testing our threading code, and may be useful just as a larger test
corpus in the future.
2017-04-13 21:55:43 -03:00

89 lines
4 KiB
Text

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