Re: [RFC] automatic CC generation for patch submission

On Sat, Jun 30, 2007 at 09:32:05AM -0700, Andrew Morton wrote:
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.

I don't see how git could tell you to Cc net patches to
netdev@xxxxxxxxxxxxxxxx

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.

Auke suggestion of an additional field in MAINTAINERS makes sense - and
it leaves it to the maintainers to maintain it similar to the other
information there.

Independent of whatever software Dan wants to write it would also solve
problems like the one that MAINTAINERS currently isn't really good in
telling e.g. who is maintaining drivers/net/wireless/.

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.

It might depend on what use cases you think of and whom you expect to
use it.

For me, a tool that simply tells me whom to Cc for a patch would be a
great tool.

What you suggest would be something completely different.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
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: [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
    ... an easier way to implement this is to add an extra field in the MAINTAINERS ... We already have that information in git. ... would you take the most common commiter, ... More majordomo info at http://vger.kernel.org/majordomo-info.html ...
    (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)
  • Re: Ingo, no more kconfig patches
    ... the .config but not quick kconfig patches that are often wrong and ... that you try to push through the maintainers as you tried here. ... You wrongly blamed Dmitry for something you broke yourself. ... There had been need of rain for many days. ...
    (Linux-Kernel)