notmuch/test/corpora/lkml/cur/1382298793.003148:2,
David Bremner 126347b694 Import notmuch_0.38.2.orig.tar.xz
[dgit import orig notmuch_0.38.2.orig.tar.xz]
2023-12-01 07:51:09 -04:00

92 lines
4.1 KiB
Text

From: Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: rfc: rewrite commit subject line for subsystem
maintainer preference tool
Date: Tue, 16 Nov 2010 15:04:51 +0000
Lines: 15
Message-ID: <20101116150451.GA26239@rakim.wolfsonmicro.main>
References: <20101115173031.GI12986@rakim.wolfsonmicro.main>
<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>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: Florian Mickler <florian@mickler.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jiri Kosina <trivial@kernel.org>, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org
To: Joe Perches <joe@perches.com>
X-From: alsa-devel-bounces@alsa-project.org Tue Nov 16 16:05:00 2010
Return-path: <alsa-devel-bounces@alsa-project.org>
Envelope-to: glad-alsa-devel-2@m.gmane.org
Received: from alsa0.perex.cz ([212.20.107.51])
by lo.gmane.org with esmtp (Exim 4.69)
(envelope-from <alsa-devel-bounces@alsa-project.org>)
id 1PIN5f-0004ME-Rp
for glad-alsa-devel-2@m.gmane.org; Tue, 16 Nov 2010 16:04:59 +0100
Received: by alsa0.perex.cz (Postfix, from userid 1000)
id E869810380D; Tue, 16 Nov 2010 16:04:57 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on mail1.perex.cz
X-Spam-Level:
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled
version=3.2.4
Received: from alsa0.perex.cz (localhost [127.0.0.1])
by alsa0.perex.cz (Postfix) with ESMTP id 159A924457;
Tue, 16 Nov 2010 16:04:57 +0100 (CET)
X-Original-To: alsa-devel@alsa-project.org
Delivered-To: alsa-devel@alsa-project.org
Received: by alsa0.perex.cz (Postfix, from userid 1000)
id 43E4E24458; Tue, 16 Nov 2010 16:04:55 +0100 (CET)
Received: from opensource2.wolfsonmicro.com (opensource.wolfsonmicro.com
[80.75.67.52]) by alsa0.perex.cz (Postfix) with ESMTP id CED8D243CD
for <alsa-devel@alsa-project.org>; Tue, 16 Nov 2010 16:04:54 +0100 (CET)
Received: from rakim.wolfsonmicro.main (lumison.wolfsonmicro.com
[87.246.78.27])
by opensource2.wolfsonmicro.com (Postfix) with ESMTPSA id A251D3B445E;
Tue, 16 Nov 2010 15:04:52 +0000 (GMT)
Received: from broonie by rakim.wolfsonmicro.main with local (Exim 4.72)
(envelope-from <broonie@rakim.wolfsonmicro.main>)
id 1PIN5X-0007x2-Qm; Tue, 16 Nov 2010 15:04:51 +0000
Content-Disposition: inline
In-Reply-To: <1289919077.28741.50.camel@Joe-Laptop>
X-Cookie: Onward through the fog.
User-Agent: Mutt/1.5.20 (2009-06-14)
X-BeenThere: alsa-devel@alsa-project.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Alsa-devel mailing list for ALSA developers -
http://www.alsa-project.org" <alsa-devel.alsa-project.org>
List-Unsubscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
<mailto:alsa-devel-request@alsa-project.org?subject=unsubscribe>
List-Archive: <http://mailman.alsa-project.org/pipermail/alsa-devel>
List-Post: <mailto:alsa-devel@alsa-project.org>
List-Help: <mailto:alsa-devel-request@alsa-project.org?subject=help>
List-Subscribe: <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>,
<mailto:alsa-devel-request@alsa-project.org?subject=subscribe>
Sender: alsa-devel-bounces@alsa-project.org
Errors-To: alsa-devel-bounces@alsa-project.org
Archived-At: <http://permalink.gmane.org/gmane.linux.kernel/1063178>
On Tue, Nov 16, 2010 at 06:51:17AM -0800, Joe Perches wrote:
> Maybe add a new MAINTAINERS section line something like:
> "C: CommitSubjectGrammarStyle"
> where CommitSubjectGrammarStyle is something more
> information rich than "style 1", "style 2".
Something printfish would seem reasonable?
> Also, what would you expect the output to be when a single
> patch modified files from 2 subsystems that use different
> styles?
The traditional thing is "ThingX/ThingY: blah" but as with anything else
you need to be sensible.