Re: [RFC] automatic CC generation for patch submission

[Adrian Bunk <bunk@stusta.de>]

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@monatomic.org> 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@intel.com> 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@vger.kernel.org.

> > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/