[RFC] automatic CC generation for patch submission

[RFC] automatic CC generation for patch submission

[Dan Aloni]

Hello,

I'd like to present a suggestion for automatic generation of 
carbon copy fields in the E-Mails of posted patches.

Basically, instead of manually figuring out who to add to CC
when sending a patch to LKML by looking at MAINTAINERS, a 
script can look at '.maintainers' files spread across the
source tree and automatically generate a proper list of CCs
for a patch.

To illustrate: If a patch affects a file under 
drivers/net/e1000, the CC script will look at these files

  drivers/net/e1000/.maintainers
  drivers/net/.maintainers
  drivers/.maintainers
  .maintainers

... to gather up the mailing list addresses or an individual 
maintainer inbox address.

A posssible format for this file could be a newline-separated
list of:

  [filename wildcard]:e-mail

For example, drivers/scsi/.maintainers would contain:

  libiscsi.*:open-iscsi@googlegroups.com
  scsi_*.c:scsi-devel@vger.kernel.org

  etc...

Or, instead (or in addition) of having a '.maintainers' file 
each directory we can modify source files by adding parsable 
'/* MAINTAINER: name@domain */' comments. 

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?

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

Re: [RFC] automatic CC generation for patch submission

[Kok, Auke]

Dan Aloni wrote:
> Hello,
> 
> I'd like to present a suggestion for automatic generation of 
> carbon copy fields in the E-Mails of posted patches.
> 
> Basically, instead of manually figuring out who to add to CC
> when sending a patch to LKML by looking at MAINTAINERS, a 
> script can look at '.maintainers' files spread across the
> source tree and automatically generate a proper list of CCs
> for a patch.
> 
> To illustrate: If a patch affects a file under 
> drivers/net/e1000, the CC script will look at these files
> 
>   drivers/net/e1000/.maintainers
>   drivers/net/.maintainers
>   drivers/.maintainers
>   .maintainers
> 
> ... to gather up the mailing list addresses or an individual 
> maintainer inbox address.
> 
> A posssible format for this file could be a newline-separated
> list of:
> 
>   [filename wildcard]:e-mail
> 
> For example, drivers/scsi/.maintainers would contain:
> 
>   libiscsi.*:open-iscsi@googlegroups.com
>   scsi_*.c:scsi-devel@vger.kernel.org
> 
>   etc...
> 
> Or, instead (or in addition) of having a '.maintainers' file 
> each directory we can modify source files by adding parsable 
> '/* MAINTAINER: name@domain */' comments. 
> 
> 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.

Auke

(horribly whitespace-mutilated copy+paste from thunderbird below)

---
diff --git a/MAINTAINERS b/MAINTAINERS
index 4c3277c..e55be49 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -69,6 +69,7 @@ L: Mailing list that is relevant to this area
  W: Web-page with status/info
  T: SCM tree type and location.  Type is one of: git, hg, quilt.
  S: Status, one of the following:
+F: Directory tree or Files belonging to this subsystem

         Supported:      Someone is actually paid to look after this.
         Maintained:     Someone actually looks after it.
@@ -1880,6 +1881,7 @@ M:        auke-jan.h.kok@intel.com
  L:     e1000-devel@lists.sourceforge.net
  W:     http://sourceforge.net/projects/e1000/
  S:     Supported
+F:     drivers/net/e100.c

  INTEL PRO/1000 GIGABIT ETHERNET SUPPORT
  P:     Jeb Cramer
@@ -1895,6 +1897,7 @@ M:        auke-jan.h.kok@intel.com
  L:     e1000-devel@lists.sourceforge.net
  W:     http://sourceforge.net/projects/e1000/
  S:     Supported
+F:     drivers/net/e1000/

  INTEL PRO/10GbE SUPPORT
  P:     Jeff Kirsher
@@ -1910,6 +1913,7 @@ M:        auke-jan.h.kok@intel.com
  L:     e1000-devel@lists.sourceforge.net
  W:     http://sourceforge.net/projects/e1000/
  S:     Supported
+F:     drivers/net/ixgb/

  INTEL PRO/WIRELESS 2100 NETWORK CONNECTION SUPPORT
  P:     Yi Zhu

Re: [RFC] automatic CC generation for patch submission

[Satyam Sharma]

On 6/30/07, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> [...]
> 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.

Hmm, associating MAINTAINERS and source files. I remember surfing LKML
archives one day and coming across this huge and ugly flamefest when some
guy called Eric S. Raymond (hehe :-) suggested something like this and got
burned.

Cheers,
S

Re: [RFC] automatic CC generation for patch submission

[Satyam Sharma]

On 6/30/07, Satyam Sharma <satyam.sharma@gmail.com> wrote:
> On 6/30/07, Kok, Auke <auke-jan.h.kok@intel.com> wrote:
> > [...]
> > 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.

Your idea is quite different though, of course.

> Hmm, associating MAINTAINERS and source files. I remember surfing LKML
> archives one day and coming across this huge and ugly flamefest when some
> guy called Eric S. Raymond (hehe :-) suggested something like this and got
> burned.

<ugh, reads again and feels stupid>

And before _I_ get burned for being impolite / provoking something, let me
clarify that the comment above was purely in spirit of humour (bad effort,
of course).

Re: [RFC] automatic CC generation for patch submission

[Andrew Morton]

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.

Not that it'll help much, given the amnount of stuff which gets
mysteriously ignored even when the correct people are cc'ed...

(For extra giggles we could parse emailed oops and bug reports and add the
appropriate cc's there too.  Harder.)

Re: [RFC] automatic CC generation for patch submission

[Dan Aloni]

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. 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.
 
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.

> Not that it'll help much, given the amnount of stuff which gets
> mysteriously ignored even when the correct people are cc'ed...

Hopefully it gets ignored if it is quite low in priority. In that
case the CC is a NOP but might still be good for archiving purposes.

> (For extra giggles we could parse emailed oops and bug reports and add the
> appropriate cc's there too.  Harder.)

BTS was discussed to death already, let's not delve into that...

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

Re: [RFC] automatic CC generation for patch submission

[Andrew Morton]

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.

> 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.

Re: [RFC] automatic CC generation for patch submission

[Adrian Bunk]

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

Re: [RFC] automatic CC generation for patch submission

[Dan Aloni]

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


Why? It shouldn't take much more effort than the effort currently
being taken to maintain the MAINTAINERS file as it is. This field can
even be considered optional - i.e. let the maintainers themselves who
usually send patches to MAINTAINERS just to update their mailing
address add this field _only if they want to_.

Heck, this way it would even help us to see which maintainers are
more attentive :)
 
> > 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.
> 

And:

c) The script will need to query vger for each file in the patch
via some protocol..

Do you think it's worth the effort?

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

Re: [RFC] automatic CC generation for patch submission

[Kok, Auke]

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.
> 
> Not that it'll help much, given the amnount of stuff which gets
> mysteriously ignored even when the correct people are cc'ed...
> 
> (For extra giggles we could parse emailed oops and bug reports and add the
> appropriate cc's there too.  Harder.)

well, I'm more thinking of the advertisement value of having some sort of 
pointer in the MAINTAINERS file to the exact location of a certain subsystem. 
Quite often I find myself searching somewhere in /drivers/ only to find out that 
the stuff I need is in asm/arch or elsewhere. E.g. alsa is a driver but lives in 
/sound/. Having a voluntary field (usable for other purposes) in the MAINTAINERS 
field seems awfully appropriate in that place and very low impact.

git does have that info, except for the fact that quite often others touch the 
same subsystem much more than the maintainer (pci, net, etc)...

Auke

Re: [RFC] automatic CC generation for patch submission

[Oleg Verych]

* Date: Sat, 30 Jun 2007 05:34:51 +0300
>
> Hello,
>
> I'd like to present a suggestion for automatic generation of 
> carbon copy fields in the E-Mails of posted patches.
>
> Basically, instead of manually figuring out who to add to CC
> when sending a patch to LKML by looking at MAINTAINERS, a 
> script can look at '.maintainers' files spread across the
> source tree and automatically generate a proper list of CCs
> for a patch.

LKML archive near you, search phrase "BTS", subjects that have
something about "the quality of the kernel". Good luck. 
____

Description in other words. Forget about scripts in source tree, tracking
and management system (as already described) is needed.

--
-o--=O`C
 #oo'L O
<___=E M

Re: [RFC] automatic CC generation for patch submission

[Dan Aloni]

On Sat, Jun 30, 2007 at 05:01:44AM +0200, Oleg Verych wrote:
> * Date: Sat, 30 Jun 2007 05:34:51 +0300
> >
> > Hello,
> >
> > I'd like to present a suggestion for automatic generation of 
> > carbon copy fields in the E-Mails of posted patches.
> >
> > Basically, instead of manually figuring out who to add to CC
> > when sending a patch to LKML by looking at MAINTAINERS, a 
> > script can look at '.maintainers' files spread across the
> > source tree and automatically generate a proper list of CCs
> > for a patch.
> 
> LKML archive near you, search phrase "BTS", subjects that have
> something about "the quality of the kernel". Good luck. 

Right, however many patches don't map to bug reports and don't 
need the heavy use of BTS. This suggestion is mainly for the 
improvement of peer review concerning code changes submitted 
by people who are not the maintainers.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

Re: [RFC] automatic CC generation for patch submission

[Oleg Verych]

On Sat, Jun 30, 2007 at 06:08:54AM +0300, Dan Aloni wrote:
> On Sat, Jun 30, 2007 at 05:01:44AM +0200, Oleg Verych wrote:
> > * Date: Sat, 30 Jun 2007 05:34:51 +0300
> > >
> > > Hello,
> > >
> > > I'd like to present a suggestion for automatic generation of 
> > > carbon copy fields in the E-Mails of posted patches.
> > >
> > > Basically, instead of manually figuring out who to add to CC
> > > when sending a patch to LKML by looking at MAINTAINERS, a 
> > > script can look at '.maintainers' files spread across the
> > > source tree and automatically generate a proper list of CCs
> > > for a patch.
> > 
> > LKML archive near you, search phrase "BTS", subjects that have
> > something about "the quality of the kernel". Good luck. 
> 
> Right, however many patches don't map to bug reports and don't 
> need the heavy use of BTS. This suggestion is mainly for the 
> improvement of peer review concerning code changes submitted 
> by people who are not the maintainers.

Unfortunately you didn't listen, OK, just two messages:

<http://permalink.gmane.org/gmane.linux.kernel/544898>
<http://permalink.gmane.org/gmane.linux.kernel/545112>

As you will see, nobody cares about comprehensive
patches/tests/bugs/testers/developers *tracking* system.

And don't limit yourself to fast conclusions. Thanks.
____

Re: [RFC] automatic CC generation for patch submission

[Dan Aloni]

On Sat, Jun 30, 2007 at 12:22:46PM +0200, Oleg Verych wrote:
> > Right, however many patches don't map to bug reports and don't 
> > need the heavy use of BTS. This suggestion is mainly for the 
> > improvement of peer review concerning code changes submitted 
> > by people who are not the maintainers.
> 
> Unfortunately you didn't listen, OK, just two messages:
> 
> <http://permalink.gmane.org/gmane.linux.kernel/544898>
> <http://permalink.gmane.org/gmane.linux.kernel/545112>
> 
> As you will see, nobody cares about comprehensive
> patches/tests/bugs/testers/developers *tracking* system.
> 
> And don't limit yourself to fast conclusions. Thanks.

I am not proposing a comprehensive tracking system. I think
you are taking my intentions quite off-course.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

Re: [RFC] automatic CC generation for patch submission

[Oleg Verych]

On Sat, Jun 30, 2007 at 01:26:01PM +0300, Dan Aloni wrote:
[]
> > As you will see, nobody cares about comprehensive
> > patches/tests/bugs/testers/developers *tracking* system.
> > 
> > And don't limit yourself to fast conclusions. Thanks.
> 
> I am not proposing a comprehensive tracking system. I think
> you are taking my intentions quite off-course.

Don't you think that organized (i.e. Cc *management*: tracking system
sends copies to _interested people_, as it was recorded earlier, or
changed due to bouncing or off-line people; by-patch tracking
of changes, tests, bugs, rc-bugs) way of dealing with patches is bad,
but yet another fancy SPAM generator script and mess in
___kernel sources___ is OK just for publishing one's patches-ches-es?

Having seen how bitkeeper improved *management* things in 2.5 - early2.6
period, i have no problem to blame propositions as yours.

Heck, going to be another useless post...
---
-o--=O`C
 #oo'L O
<___=E M

Re: [RFC] automatic CC generation for patch submission

[Adrian Bunk]

On Sat, Jun 30, 2007 at 05:34:51AM +0300, Dan Aloni wrote:
>...
> Basically, instead of manually figuring out who to add to CC
> when sending a patch to LKML by looking at MAINTAINERS, a 
> script can look at '.maintainers' files spread across the
> source tree and automatically generate a proper list of CCs
> for a patch.
>...
> To illustrate: If a patch affects a file under 
> drivers/net/e1000, the CC script will look at these files
> 
>   drivers/net/e1000/.maintainers
>   drivers/net/.maintainers
>   drivers/.maintainers
>   .maintainers
> 
> ... to gather up the mailing list addresses or an individual 
> maintainer inbox address.
>...
> Any comments?

As Auke said, maintaining the information in MAINTAINERS would be 
better.

And another important use case that shouldn't require much extra work 
would be to do the same for bug reports.

Generally, you should keep in mind that it must fit into the workflow of 
the people who should use it. E.g. I could imagine that it might make 
more sense if you write a small tool that takes a patch or a path and 
outputs email addresses instead of a huge tool that tries to solve too 
many problems at once and doesn't fit into the workflow of most people.

> Dan Aloni

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

Re: [RFC] automatic CC generation for patch submission

[Dan Aloni]

On Sat, Jun 30, 2007 at 06:01:23AM +0200, Adrian Bunk wrote:
> On Sat, Jun 30, 2007 at 05:34:51AM +0300, Dan Aloni wrote:
> >...
> > Basically, instead of manually figuring out who to add to CC
> > when sending a patch to LKML by looking at MAINTAINERS, a 
> > script can look at '.maintainers' files spread across the
> > source tree and automatically generate a proper list of CCs
> > for a patch.
> >...
> > To illustrate: If a patch affects a file under 
> > drivers/net/e1000, the CC script will look at these files
> > 
> >   drivers/net/e1000/.maintainers
> >   drivers/net/.maintainers
> >   drivers/.maintainers
> >   .maintainers
> > 
> > ... to gather up the mailing list addresses or an individual 
> > maintainer inbox address.
> >...
> > Any comments?
> 
> As Auke said, maintaining the information in MAINTAINERS would be 
> better.

Yes, I tend to agree.
 
> And another important use case that shouldn't require much extra work 
> would be to do the same for bug reports.

Yes, however for bug reports it isn't always possible to tell which
subsystem or files would get fixed once the bug is understood. 
Perhaps it would be good once the bug report reaches the stage where 
patches are made.

> Generally, you should keep in mind that it must fit into the workflow of 
> the people who should use it. E.g. I could imagine that it might make 
> more sense if you write a small tool that takes a patch or a path and 
> outputs email addresses instead of a huge tool that tries to solve too 
> many problems at once and doesn't fit into the workflow of most people.

I absolutely agree - in fact I was thinking of this as a nice
addition to scripts/checkpatch.pl. For example:

   Your patch has no obvious style problems and is ready for submission.
   When submitting this particular patch, you should CC to:

   e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org

However my Perl hacking capabilities (or incapabilities thereof) 
wouldn't do good to that script I suppose.

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il

Re: [RFC] automatic CC generation for patch submission

[Adrian Bunk]

On Sat, Jun 30, 2007 at 12:47:11PM +0300, Dan Aloni wrote:
> On Sat, Jun 30, 2007 at 06:01:23AM +0200, Adrian Bunk wrote:
> > On Sat, Jun 30, 2007 at 05:34:51AM +0300, Dan Aloni wrote:
> > >...
> > > Basically, instead of manually figuring out who to add to CC
> > > when sending a patch to LKML by looking at MAINTAINERS, a 
> > > script can look at '.maintainers' files spread across the
> > > source tree and automatically generate a proper list of CCs
> > > for a patch.
> > >...
> > > To illustrate: If a patch affects a file under 
> > > drivers/net/e1000, the CC script will look at these files
> > > 
> > >   drivers/net/e1000/.maintainers
> > >   drivers/net/.maintainers
> > >   drivers/.maintainers
> > >   .maintainers
> > > 
> > > ... to gather up the mailing list addresses or an individual 
> > > maintainer inbox address.
> > >...
> > > Any comments?
> > 
> > As Auke said, maintaining the information in MAINTAINERS would be 
> > better.
> 
> Yes, I tend to agree.
>  
> > And another important use case that shouldn't require much extra work 
> > would be to do the same for bug reports.
> 
> Yes, however for bug reports it isn't always possible to tell which
> subsystem or files would get fixed once the bug is understood. 
> Perhaps it would be good once the bug report reaches the stage where 
> patches are made.

Don't aim for perfection.

If your program also accepts a path or file as input (instead of 
extracting it from a patch) you'll get it with nearly zero extra effort.

> > Generally, you should keep in mind that it must fit into the workflow of 
> > the people who should use it. E.g. I could imagine that it might make 
> > more sense if you write a small tool that takes a patch or a path and 
> > outputs email addresses instead of a huge tool that tries to solve too 
> > many problems at once and doesn't fit into the workflow of most people.
> 
> I absolutely agree - in fact I was thinking of this as a nice
> addition to scripts/checkpatch.pl. For example:
> 
>    Your patch has no obvious style problems and is ready for submission.
>    When submitting this particular patch, you should CC to:
> 
>    e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org

checkpatch.pl checks a patch, not an email.

And e.g. in my workflow there isn't any technical correlation between 
some "Cc:" field in a patch and the recipients of the email containing 
it since I'm not using any fancy scripts for maintaining and sending 
patches.

> However my Perl hacking capabilities (or incapabilities thereof) 
> wouldn't do good to that script I suppose.

A tool that simply would output some email addresses to Cc when given a 
patch is something I would most likely use since it would fit in my 
workflow and replace manual looks at MAINTAINERS.

Something big is less likely to be adapted unless it nearly perfectly 
suits the needs of the people intended to use it.

But it's your program, so it's your choice what you implement and in 
what language you implement it.

> Dan Aloni

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