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.*:[email protected]
scsi_*.c:[email protected]
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
* 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
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.*:[email protected]
> scsi_*.c:[email protected]
>
> 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: [email protected]
L: [email protected]
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: [email protected]
L: [email protected]
W: http://sourceforge.net/projects/e1000/
S: Supported
+F: drivers/net/e1000/
INTEL PRO/10GbE SUPPORT
P: Jeff Kirsher
@@ -1910,6 +1913,7 @@ M: [email protected]
L: [email protected]
W: http://sourceforge.net/projects/e1000/
S: Supported
+F: drivers/net/ixgb/
INTEL PRO/WIRELESS 2100 NETWORK CONNECTION SUPPORT
P: Yi Zhu
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
On 6/30/07, Kok, Auke <[email protected]> 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
On 6/30/07, Satyam Sharma <[email protected]> wrote:
> On 6/30/07, Kok, Auke <[email protected]> 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).
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
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:
[email protected], [email protected]
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
On Fri, 29 Jun 2007 19:51:53 -0700 "Kok, Auke" <[email protected]> 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.)
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.
____
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
On Sat, Jun 30, 2007 at 02:54:25AM -0700, Andrew Morton wrote:
> On Fri, 29 Jun 2007 19:51:53 -0700 "Kok, Auke" <[email protected]> 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
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
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:
>
> [email protected], [email protected]
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
Andrew Morton wrote:
> On Fri, 29 Jun 2007 19:51:53 -0700 "Kok, Auke" <[email protected]> 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
On Sat, 30 Jun 2007 13:47:52 +0300 Dan Aloni <[email protected]> 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" <[email protected]> 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.
On Sat, Jun 30, 2007 at 09:32:05AM -0700, Andrew Morton wrote:
> On Sat, 30 Jun 2007 13:47:52 +0300 Dan Aloni <[email protected]> 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" <[email protected]> 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
[email protected].
> > 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
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