X-Git-Url: https://git.notmuchmail.org/git?a=blobdiff_plain;f=test%2Fcorpora%2Flkml%2Fcur%2F1382298793.004091%3A2%2C;fp=test%2Fcorpora%2Flkml%2Fcur%2F1382298793.004091%3A2%2C;h=1abc297fca460980828f1aab03ba6a0e300c9532;hb=e08f5f76e406de2c6bdcf85952aaeb66ec0d37de;hp=0000000000000000000000000000000000000000;hpb=ce8c88824ab91882ea50c761b930390953cf2c34;p=notmuch diff --git a/test/corpora/lkml/cur/1382298793.004091:2, b/test/corpora/lkml/cur/1382298793.004091:2, new file mode 100644 index 00000000..1abc297f --- /dev/null +++ b/test/corpora/lkml/cur/1382298793.004091:2, @@ -0,0 +1,133 @@ +From: Stefan Richter +Subject: Re: rfc: rewrite commit subject line for subsystem maintainer + preference tool +Date: Wed, 17 Nov 2010 22:07:37 +0100 +Lines: 74 +Message-ID: <20101117220737.2d3d7356@stein> +References: <20101116104921.GL12986@rakim.wolfsonmicro.main> + <1289919077.28741.50.camel@Joe-Laptop> + <20101116183707.179964dd@schatten.dmk.lab> + <20101116181226.GB26239@rakim.wolfsonmicro.main> + <20101116203522.65240b18@schatten.dmk.lab> + <20101116195530.GA7523@rakim.wolfsonmicro.main> + <20101116122102.86e7e0b9.rdunlap@xenotime.net> + <20101116230126.GB24623@opensource.wolfsonmicro.com> + <20101117014427.41d85b13@stein> + + <20101117170746.GB19488@rakim.wolfsonmicro.main> +Mime-Version: 1.0 +Content-Type: text/plain; charset=US-ASCII +Content-Transfer-Encoding: 7bit +Cc: Jiri Kosina , Randy Dunlap , + Florian Mickler , + Joe Perches , + Andrew Morton , + alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org +To: Mark Brown +X-From: linux-kernel-owner@vger.kernel.org Wed Nov 17 22:08:15 2010 +Return-path: +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 ) + id 1PIpEk-0006ge-Hz + for glk-linux-kernel-3@lo.gmane.org; Wed, 17 Nov 2010 22:08:14 +0100 +Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand + id S1758632Ab0KQVHz (ORCPT ); + Wed, 17 Nov 2010 16:07:55 -0500 +Received: from einhorn.in-berlin.de ([192.109.42.8]:48630 "EHLO + einhorn.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org + with ESMTP id S1751563Ab0KQVHy (ORCPT + ); + Wed, 17 Nov 2010 16:07:54 -0500 +X-Envelope-From: stefanr@s5r6.in-berlin.de +Received: from stein ([83.221.231.7]) + (authenticated bits=0) + by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id oAHL7dhi014114 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); + Wed, 17 Nov 2010 22:07:39 +0100 +In-Reply-To: <20101117170746.GB19488@rakim.wolfsonmicro.main> +X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-pc-linux-gnu) +X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 +Sender: linux-kernel-owner@vger.kernel.org +Precedence: bulk +List-ID: +X-Mailing-List: linux-kernel@vger.kernel.org +Archived-At: + +On Nov 17 Mark Brown wrote: +> On Wed, Nov 17, 2010 at 01:53:35AM +0100, Jiri Kosina wrote: +> > On Wed, 17 Nov 2010, Stefan Richter wrote: +> +> > > Why should we codify our conventions in MAINTAINERS to accommodate the +> > > specific problem of virtually a _single_ patch author? +> +> It seems to be the way we're heading in general - look at all the recent +> work on MAINTAINERS and get_maintainer.pl. There seems to be a genral +> push to make all this stuff automatable. + +get_maintainer.pl, used with judgment and together with "gitk +the/patched/source.c" is nice not only for people like Joe who +regularly work tree-wide but also for ones like me who only rarely want +to submit a bug report or patch for a subsystem with they are +unfamiliar with. + +But the thought of a database of "how to start a good patch title" is +far-fetched. Really, as a patch author, just look how other people +write patch titles and judge whether this is good for your work too or +not. + +> > Either the maintainer wants the patch. Then he is certainly able to apply +> > it no matter the subject line (I personally am getting a lot of patches +> > which don't follow the format I am using in my tree ... converting +> > Subject: lines is so trivial that I have never felt like bothering anyone +> > about it ... it's basically single condition in a shellscript). Or the +> +> It's slightly more than that if you're dealing with more than one area, +> and I also find this sort of stuff is a good flag for scrubbing the +> patch in greater detail - when patches stand out from a 1000ft visual +> overview there's a fair chance that there's other issues so if people +> regularly submit good patches that have only cosmetic issues I find it's +> worth guiding them away from that. + +On one hand Jiri is right that maintainers can adjust title prefixes ad +hoc. (Downside: Weaker connection to mailinglist archives.) On the +other hand, in the case of long-term prolific authors like Joe it is +more optimal if there is a good patch title right from the outset. + +So, if this boring thread does at least yield the conclusion that +${path}/${filename}: is a bad title prefix, at least something was +won. :-) + +Another thought: Whether a typical part of a mass conversion, e.g. to +use a new helper macro without change of functionality, is named + + [PATCH] [subsystem] driver: use foo_bar helper +or + [PATCH] use foo_bar helper in subsystem, driver + +does not really matter, does it? This change is more about the helper +than about the driver. It is really a different kind of changeset than +a functional change that we want to be called + + [PATCH] [subsystem] driver: fix crash at disconnection + +or so. This is something that those who look for release notes of +that driver or subsystem want to grep in the changelog. + +Or in other words: If you as patch author wonder what would be a good +title for your patch, then ask yourself: How should this change show up +in kernel release notes that are constructed from the git shortlog? +Sometimes the answer to this question includes among else a prefix with +a canonical subsystem name (even case sensitive, with brackets or +colon), whereas other times such formalities are utterly pointless. + +[Sorry for the spent electrons. But OTOH, issues like (1.) optimum +use of reviewer bandwidth, (2.) kernel changelog alias release +notes /do/ matter.] +-- +Stefan Richter +-=====-==-=- =-== =---= +http://arcgraph.de/sr/ + +