Re: [RFC] automatic CC generation for patch submission

On Sat, 30 Jun 2007 13:47:52 +0300 Dan Aloni <da-x@xxxxxxxxxxxxx> wrote:

On Sat, Jun 30, 2007 at 02:54:25AM -0700, Andrew Morton wrote:
On Fri, 29 Jun 2007 19:51:53 -0700 "Kok, Auke" <auke-jan.h.kok@xxxxxxxxx> wrote:

Some extensions to the popular E-Mail clients might be needed
here. Also, a bot reading LKML would automatically send links
about posted patches to the other mailing lists whenever
someone forgets to add a CC.

Any comments?

an easier way to implement this is to add an extra field in the MAINTAINERS
file, something like below. All the contact info would stay the same, closely
where applicable and it would allow you to also specify specific files as well.

We already have that information in git. Parse the git changelogs of the
affected files, find out who works on them.

I think it's quite complex to make a reliable inference of maintainership
information from git.

Clever people will work it out.

Given a set of historical modifiers of a file,
would you take the most common commiter(s), or the most common
_recent_ commiter(s), or what? It's a bit fuzzy.

All the above? Multiply frequency by recency, pick the top five?

Doesn't matter much: the cost of picking too many is high.

I shudder at the thought of manually maintaining anything like this.

Moreover, it is slow in comparison and assumes the availability of
local .git db, which wouldn't be the case for some porition of patch
submitters.

a) precalculate the tables once per week

b) the whole thing wouldn't succeed if it requires software at
patch-submitter's site. It'd need to run at vger.

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

Relevant Pages

  • Re: [RFC] automatic CC generation for patch submission
    ... We already have that information in git. ... would you take the most common commiter, ... Dan Aloni ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
    (Linux-Kernel)
  • Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch - scripts/get_maintainer.pl
    ... I do not think adding 600+ patches to ... suggested for MAINTAINERS, would make a lot more sense. ... There's really not much point in pretending that non-git users are still first class citizens anyway; Linus' own suggestion of using git-blame would tie things to git as well, as do for example frequent requests to bisect a problem. ... It's the kernel's source code management tool, is included out of the box in most distributions nowadays and is GPLd meaning that the tool won't keep anyone from exporting data from it and importing it into something else if someone cares to. ...
    (Linux-Kernel)
  • Re: [RFC] automatic CC generation for patch submission
    ... about posted patches to the other mailing lists whenever ... an easier way to implement this is to add an extra field in the MAINTAINERS ... We already have that information in git. ... There had been need of rain for many days. ...
    (Linux-Kernel)
  • Re: Make the git URL match usage
    ... MAINTAINERS file, even the ones that I didn't have to modify. ... in the same git repository, but fail when I attempt git clone ... listing the trees anyway pointless. ... There had been need of rain for many days. ...
    (Linux-Kernel)
  • Re: [PATCH] [545/2many] MAINTAINERS - XEN HYPERVISOR INTERFACE
    ... Between git, existing MAINTAINERS and a bit of common ... all of MAINTAINERS info, it could be a tag to reference the relevant ... There had been need of rain for many days. ...
    (Linux-Kernel)