linux-kernel - Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 14 Aug 2007 18:31:58 -0700
From:	Junio C Hamano <gitster@...ox.com>
To:	Joe Perches <joe@...ches.com>
Cc:	Rene Herman <rene.herman@...il.com>, git@...r.kernel.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org
Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

Joe Perches <joe@...ches.com> writes:

> On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:
>> It isn't about MODULE_FOO() tags, it is about tagging /source/ files 
>> to help with putting CCs on patch submissals.
>> If we want to link source file foo.c and the 
>> MAINTAINERS information, we have 3 options:
>> 1. MAINTAINERS --> foo.c
>> 2. foo.c --> MAINTAINERS
>> 3. foo.c <--> some 3rd file <--> MAINTAINERS
>
> I added git@...r.kernel.org and Junio Hamano
>
> Another possibility is improving git to allow
> some sort of "declaration of interest" in bits
> of projects.
>
> That would allow options like:
>
> o  git-format-patch to include CCs
> o  git-commit and git-branch to notify or
>      take some other action
>
> etc...

There are things git can help, and other things git does not
have any business with.

1. Finding out who the potentially interested parties are.

   Linus already gave a script to grep *-by: lines from commit
   messages.  I find this is probably be the best option, as it
   follows "yesterday's weather".  People who had dealt with the
   area are the ones who are likely to be interested.

   git records who did the work (author) and who did the
   integration to git-based patch flow (committer).  It does not
   structurally track intermediate people who touched the patch
   on e-mail, but Signed-off-by: and Acked-by: (and sometimes I
   see Cc: as well in the commit messages) are accepted social
   convention in the kernel community, and taking advantage of
   that is a good idea.

2. Making it easier to send your patches to these people.

   There are three possible places to add Signed-off-by: and
   friends in the commit messages you would mail out:

   - When you create your own commit, or commit a patch that
     came to you via e-mail.  The commit object in your tree
     will carry them --- you can send format-patch output as-is
     to Linus or Andrew and you are done.

   - When you run format-patch; your commit will not have extra
     Cc: or "interested parties" information, you will use the
     result of 1. and insert it near your own Signed-off-by: to
     the format-patch output.

   - When you send format-patch output, via git-send-email
     perhaps.

   To make the result useful for "yesterday's weather" approach,
   I think it would be the best to do the first.  After all,
   your commit may propagate via "git pull" not over e-mail, and
   no postprocessing approach would work in such a case.

   The second one is my least favorite.  format-patch output is
   designed to record author/committer (i.e. origin) and not to
   record recipient at all.  "Who's interested in this" does not
   simply belong there.

   On the other hand, git-send-email _is_ all about sending it
   out, and it needs to know who your patch should reach.  I
   think it makes sense to have one script that, given a set of
   paths that are affected, gives a list of potentially
   interested people (that is "Finding" part -- and I see there
   are 600+ patches to implement this on the list), and a new
   option to git-send-email to (1) inspect the patch to see what
   paths are affected, and (2) call that "Find" script to figure
   out whom to send it to, and probably asking for confirmation.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/