MODULE_MAINTAINER

MODULE_MAINTAINER

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

Hi Rusty.

Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?

Often a module grows multiple authors over time, but initial authors 
aren't around (or too interested) anymore. And sometimes, if someone 
maintaining a driver is just doing minor peripheral updates to keep it 
compiling, the maintainer might not even _be_ an author really...

Rene.



[-- Attachment #2: module_maintainer.diff --]
[-- Type: text/plain, Size: 595 bytes --]

diff --git a/include/linux/module.h b/include/linux/module.h
index 10f771a..c06f76c 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -128,6 +128,9 @@ #define MODULE_LICENSE(_license) MODULE_
 /* Author, ideally of form NAME <EMAIL>[, NAME <EMAIL>]*[ and NAME <EMAIL>] */
 #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
   
+/* Maintainer, ideally of form NAME <EMAIL> */
+#define MODULE_MAINTAINER(_maintainer) MODULE_INFO(maintainer, _maintainer)
+
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 

Re: MODULE_MAINTAINER

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

On 04/04/2007 01:26 PM, Rene Herman wrote:

> Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?

And here's the accompanying patch to the module-init-tools-3.3-pre1 as 
found on http://kernel.org/pub/linux/utils/kernel/module-init-tools/

Rene.

[-- Attachment #2: modinfo_maintainer.diff --]
[-- Type: text/plain, Size: 763 bytes --]

--- module-init-tools-3.3-pre1/modinfo.c.orig	2007-04-04 12:54:19.000000000 +0200
+++ module-init-tools-3.3-pre1/modinfo.c	2007-04-04 12:59:42.000000000 +0200
@@ -213,6 +213,7 @@
 static struct option options[] =
 {
 	{"author", 0, 0, 'a'},
+	{"maintainer", 0, 0, 'm'},
 	{"description", 0, 0, 'd'},
 	{"license", 0, 0, 'l'},
 	{"parameters", 0, 0, 'p'},
@@ -347,9 +348,10 @@
 	else
 		abort();
 
-	while ((opt = getopt_long(argc,argv,"adlpVhn0F:",options,NULL)) >= 0){
+	while ((opt = getopt_long(argc,argv,"amdlpVhn0F:",options,NULL)) >= 0){
 		switch (opt) {
 		case 'a': field = "author"; break;
+		case 'm': field = "maintainer"; break;	  
 		case 'd': field = "description"; break;
 		case 'l': field = "license"; break;
 		case 'p': field = "parm"; break;

Re: MODULE_MAINTAINER

[Christoph Hellwig]

On Wed, Apr 04, 2007 at 01:26:04PM +0200, Rene Herman wrote:
> Hi Rusty.
> 
> Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?

#define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
MODULE_AUTHOR really has meant maintainer in practice for ages, and it's
the only actually relevant for users information we should store.

Re: MODULE_MAINTAINER

[Rene Herman]

On 04/04/2007 02:33 PM, Christoph Hellwig wrote:

> On Wed, Apr 04, 2007 at 01:26:04PM +0200, Rene Herman wrote:

>> Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
> 
> #define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
> MODULE_AUTHOR really has meant maintainer in practice for ages, and it's
> the only actually relevant for users information we should store.

Given modules with multiple authors, current and non-current, I believe 
having "modinfo -m" tell the user whom to contact is an avantage.

Rene.

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Wed, Apr 04, 2007 at 03:02:41PM +0200, Rene Herman wrote:
> On 04/04/2007 02:33 PM, Christoph Hellwig wrote:
> 
> >On Wed, Apr 04, 2007 at 01:26:04PM +0200, Rene Herman wrote:
> 
> >>Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
> >
> >#define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
> >MODULE_AUTHOR really has meant maintainer in practice for ages, and it's
> >the only actually relevant for users information we should store.
> 
> Given modules with multiple authors, current and non-current, I believe 
> having "modinfo -m" tell the user whom to contact is an avantage.

Much bigger problems are:
- Who will maintain this information properly?
- What about modules that are maintained implicitely by the subsystem
  maintainer?

And often a user can't be expected to locate the source of a problem, or 
it might not be in a driver but in a subsystem.

For vendor kernels, the user should contact the vendor.
For ftp.kernel.org kernels, I don't see any better solution than telling 
people to report problems to linux-kernel or the kernel Bugzilla and 
routing them further from here.

> Rene.

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: MODULE_MAINTAINER

[Stefan Richter]

Adrian Bunk wrote:
> On Wed, Apr 04, 2007 at 03:02:41PM +0200, Rene Herman wrote:
>> Given modules with multiple authors, current and non-current, I believe 
>> having "modinfo -m" tell the user whom to contact is an avantage.
> 
> Much bigger problems are:
> - Who will maintain this information properly?
> - What about modules that are maintained implicitely by the subsystem
>   maintainer?
> 
> And often a user can't be expected to locate the source of a problem, or 
> it might not be in a driver but in a subsystem.
> 
> For vendor kernels, the user should contact the vendor.
> For ftp.kernel.org kernels, I don't see any better solution than telling 
> people to report problems to linux-kernel or the kernel Bugzilla and 
> routing them further from here.

Generelly it has to be kept in mind that there are different contacts
for different purposes:
  - usage problems --> get in touch with the _support_
  - bug reports --> get in touch with _maintainers_
  - development --> get in touch with maintainers/ kernel hackers/
    copyright holders...

The Amiga keyboard had a [Help] key, but this is not how it works.
-- 
Stefan Richter
-=====-=-=== -=-- --=--
http://arcgraph.de/sr/

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Wed, Apr 04, 2007 at 06:33:06PM +0200, Stefan Richter wrote:
> Adrian Bunk wrote:
> > On Wed, Apr 04, 2007 at 03:02:41PM +0200, Rene Herman wrote:
> >> Given modules with multiple authors, current and non-current, I believe 
> >> having "modinfo -m" tell the user whom to contact is an avantage.
> > 
> > Much bigger problems are:
> > - Who will maintain this information properly?
> > - What about modules that are maintained implicitely by the subsystem
> >   maintainer?
> > 
> > And often a user can't be expected to locate the source of a problem, or 
> > it might not be in a driver but in a subsystem.
> > 
> > For vendor kernels, the user should contact the vendor.
> > For ftp.kernel.org kernels, I don't see any better solution than telling 
> > people to report problems to linux-kernel or the kernel Bugzilla and 
> > routing them further from here.
> 
> Generelly it has to be kept in mind that there are different contacts
> for different purposes:
>   - usage problems --> get in touch with the _support_
>   - bug reports --> get in touch with _maintainers_

- bug reports against vendor kernels -> get in touch with the _vendor_
  (the vendor might ship a heavily patched driver in an ancient kernel)

>   - development --> get in touch with maintainers/ kernel hackers/
>     copyright holders...
> 
> The Amiga keyboard had a [Help] key, but this is not how it works.

> Stefan Richter

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: MODULE_MAINTAINER

[Stefan Richter]

Adrian Bunk wrote:
> On Wed, Apr 04, 2007 at 06:33:06PM +0200, Stefan Richter wrote:
>>   - usage problems --> get in touch with the _support_
>>   - bug reports --> get in touch with _maintainers_
> 
> - bug reports against vendor kernels -> get in touch with the _vendor_
>   (the vendor might ship a heavily patched driver in an ancient kernel)

Yes, of course. I implicitly meant the maintainer of the program as
distributed, which in case of distro kernels are the distributor's
kernel maintainers... :-)

Also, "get in touch" almost never means "send personal e-mail", but
rather to use bugzillas, mailing lists, discussion forums etc.
-- 
Stefan Richter
-=====-=-=== -=-- --=--
http://arcgraph.de/sr/

Re: MODULE_MAINTAINER

[Marcel Holtmann]

Hi Christoph,

> > Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
> 
> #define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
> MODULE_AUTHOR really has meant maintainer in practice for ages, and it's
> the only actually relevant for users information we should store.

I agree. The actual author information belong into the files copyright
header. The MODULE_AUTHOR should only show the current maintainer and
its email address. However this might need some cleanup. Maybe it is
time that we sync the MAINTAINERS file with the MODULE_AUTHOR tag.

Regards

Marcel

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Wed, Apr 04, 2007 at 04:48:55PM +0200, Marcel Holtmann wrote:
> Hi Christoph,
> 
> > > Can we have a MODULE_MAINTAINER to complement MODULE_AUTHOR?
> > 
> > #define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please.
> > MODULE_AUTHOR really has meant maintainer in practice for ages, and it's
> > the only actually relevant for users information we should store.
> 
> I agree. The actual author information belong into the files copyright
> header. The MODULE_AUTHOR should only show the current maintainer and
> its email address. However this might need some cleanup. Maybe it is
> time that we sync the MAINTAINERS file with the MODULE_AUTHOR tag.

Or even remove the MODULE_AUTHOR tag?

Even if you would spend the time for syncing the > 1600 MODULE_AUTHOR 
tags today, I don't see this happen on an ongoing basis in the future.

> Regards
> 
> Marcel

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: MODULE_MAINTAINER

[Rene Herman]

On 04/04/2007 05:02 PM, Adrian Bunk wrote:

>>> #define MODULE_MAINTAINER(x) MODULE_AUTHOR(x), please. 
>>> MODULE_AUTHOR really has meant maintainer in practice for ages,
>>> and it's the only actually relevant for users information we
>>> should store.
>> 
>> I agree. The actual author information belong into the files
>> copyright header. The MODULE_AUTHOR should only show the current
>> maintainer and its email address. However this might need some
>> cleanup. Maybe it is time that we sync the MAINTAINERS file with
>> the MODULE_AUTHOR tag.
> 
> Or even remove the MODULE_AUTHOR tag?
> 
> Even if you would spend the time for syncing the > 1600 MODULE_AUTHOR
> tags today, I don't see this happen on an ongoing basis in the
> future.

Given that people seem to agree that authorship information has no place 
in the binary, that might actually be best.

The problem I'm trying to solve is letting people know whom to contact. 
Having multiple authors in the MODULES_AUTHOR tag and maintainers who 
might not be authors are two reasons the current tag doesn't work.

Keeping copyright holders in a copyright header and maintainers in the 
MAINTAINERS file would at least avoid the confusing message the tag 
sends. As you say in a previous message, users should mostly in fact be 
contacting their vendor if using distro kernels or, if they're using 
kermel.org kernels, linux-kernel and can then find the information in 
the MAINTAINERS file.

So, MODULE_AUTHOR be gone?

Rene.

Re: MODULE_MAINTAINER

[Alan Cox]

> Given that people seem to agree that authorship information has no place 
> in the binary, that might actually be best.

Authorship information is very useful in the binary, especially when you
have to get lawyers involved in explaining things to people. Company
business and management people understand

"load it into a binary editor, search for Alan Cox, now call your lawyer"

trying to prove a given source is a given binary is much much harder.

> So, MODULE_AUTHOR be gone?

Not if I have anything to do with it. Putting maintainer in is not a bad
idea but that assumes it gets maintained, the beauty of _AUTHOR is that
it's generally right and stays that way or approximately so.

Alan

Re: MODULE_MAINTAINER

[Marcel Holtmann]

Hi Alan,

> > Given that people seem to agree that authorship information has no place 
> > in the binary, that might actually be best.
> 
> Authorship information is very useful in the binary, especially when you
> have to get lawyers involved in explaining things to people. Company
> business and management people understand
> 
> "load it into a binary editor, search for Alan Cox, now call your lawyer"
> 
> trying to prove a given source is a given binary is much much harder.
> 
> > So, MODULE_AUTHOR be gone?
> 
> Not if I have anything to do with it. Putting maintainer in is not a bad
> idea but that assumes it gets maintained, the beauty of _AUTHOR is that
> it's generally right and stays that way or approximately so.

removing the MODULE_AUTHOR is a bad idea. I really like to call modinfo
and see who maintains a specific driver.

Regards

Marcel

Re: MODULE_MAINTAINER

[Rene Herman]

On 04/04/2007 06:00 PM, Alan Cox wrote:

>> Given that people seem to agree that authorship information has no place 
>> in the binary, that might actually be best.
> 
> Authorship information is very useful in the binary, especially when you
> have to get lawyers involved in explaining things to people.

Okay.

>> So, MODULE_AUTHOR be gone?
> 
> Not if I have anything to do with it. Putting maintainer in is not a
> bad idea but that assumes it gets maintained, the beauty of _AUTHOR
> is that it's generally right and stays that way or approximately so.

Case in point; someone is working with me in private on a new "mitsumi" 
legacy CD-ROM driver. He's authoring the actual driver and upto now I've 
just been doing some peripheral module infrastructure work. Given that I 
have the hardware to test the thing, I'll be the maintainer though.

Adding myself as a MODULE_AUTHOR would be largely incorrect and adding 
myself as the _only_ MODULE_AUTHOR would be so factually incorrect I 
wouldn't, even if only from a credits point of view. Yet I do want to 
make sure people contact me, and not the MODULE_AUTHOR (which will 
happen no matter the MAINTAINERS file).

Other cases-in-point; I've lately been rummaging through sound/isa a 
bit. Nothing much copyrightable again but especially in those situations 
where (some of the) original authors are no longer active, I do again 
want people to contact me about them if needed. And all the "which one 
of the three people listed here is maintaining this" is yet another.

MODULE_AUTHOR may be approximately right but especially with old drivers 
it also has little relation with who's maintaining the thing.

If MODULE_AUTHOR stays, can I just have MODULE_MAINTAINER please? It 
doesn't need to be added to drivers directly, it can just grow (and 
being inside the code, I suppose it'll likely stay up to date better 
than the MAINTAINERS file).

Rene.

Re: MODULE_MAINTAINER

[Takashi Iwai]

At Wed, 04 Apr 2007 18:38:42 +0200,
Rene Herman wrote:
> 
> Other cases-in-point; I've lately been rummaging through sound/isa a 
> bit. Nothing much copyrightable again but especially in those situations 
> where (some of the) original authors are no longer active, I do again 
> want people to contact me about them if needed. And all the "which one 
> of the three people listed here is maintaining this" is yet another.

Practically, the information can go through subsystem maintainers to
specific person (you) in such a case, as the tree is still more or
less maintained by subsystem maintainers.

But in general, it would be nice to have an easy way to find a
maintainer (not author) from a module binary, and I agree
MODULE_MAINTAINER can work well for such a purpose.  It's no mandatory
field, but could be some help.


Takashi

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Wed, Apr 04, 2007 at 07:00:18PM +0200, Takashi Iwai wrote:
> At Wed, 04 Apr 2007 18:38:42 +0200,
> Rene Herman wrote:
> > 
> > Other cases-in-point; I've lately been rummaging through sound/isa a 
> > bit. Nothing much copyrightable again but especially in those situations 
> > where (some of the) original authors are no longer active, I do again 
> > want people to contact me about them if needed. And all the "which one 
> > of the three people listed here is maintaining this" is yet another.
> 
> Practically, the information can go through subsystem maintainers to
> specific person (you) in such a case, as the tree is still more or
> less maintained by subsystem maintainers.
> 
> But in general, it would be nice to have an easy way to find a
> maintainer (not author) from a module binary, and I agree
> MODULE_MAINTAINER can work well for such a purpose.  It's no mandatory
> field, but could be some help.

Yes, it would be nice.

But would this information always be kept up-to-date for the whole tree?
I don't see this happen.

> Takashi

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: MODULE_MAINTAINER

[Rene Herman]

On 04/04/2007 07:48 PM, Adrian Bunk wrote:

> On Wed, Apr 04, 2007 at 07:00:18PM +0200, Takashi Iwai wrote:

>> But in general, it would be nice to have an easy way to find a
>> maintainer (not author) from a module binary, and I agree
>> MODULE_MAINTAINER can work well for such a purpose.  It's no mandatory
>> field, but could be some help.
> 
> Yes, it would be nice.
> 
> But would this information always be kept up-to-date for the whole tree?
> I don't see this happen.

I believe it would largely stay up to date yes. The tag wouldn't be 
mandatory and adding oneself as a MODULE_MAINTAINER would specifically 
be saying "yes, I want to look after this thing". If someone then no 
longer wants to, getting rid of the tag is a matter of deleting one 
line. I wouldn't be worse than MAINTAINERS, and being inline, I expect 
it to be better...

Rene.

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Wed, Apr 04, 2007 at 08:01:31PM +0200, Rene Herman wrote:
> On 04/04/2007 07:48 PM, Adrian Bunk wrote:
> 
> >On Wed, Apr 04, 2007 at 07:00:18PM +0200, Takashi Iwai wrote:
> 
> >>But in general, it would be nice to have an easy way to find a
> >>maintainer (not author) from a module binary, and I agree
> >>MODULE_MAINTAINER can work well for such a purpose.  It's no mandatory
> >>field, but could be some help.
> >
> >Yes, it would be nice.
> >
> >But would this information always be kept up-to-date for the whole tree?
> >I don't see this happen.
> 
> I believe it would largely stay up to date yes. The tag wouldn't be 
> mandatory and adding oneself as a MODULE_MAINTAINER would specifically 
> be saying "yes, I want to look after this thing". If someone then no 
> longer wants to, getting rid of the tag is a matter of deleting one 
> line. I wouldn't be worse than MAINTAINERS, and being inline, I expect 
> it to be better...

- often module maintainers disappear suddenly or slowly without any
  clear statement that maintainership ended
- most drivers are not maintained on a per-driver but on a per-subsystem
  basis

Consider that we don't even manage to keep MAINTAINERS correct, and 
consider that we are talking about more than 2800 modules.

Realistically, users should report problems with vendor kernels to the 
vendor and problems with ftp.kernel.org kernels to either linux-kernel 
or the kernel Bugzilla, and forwarding issues to the responsible people 
(if any) should be done there [1].

> Rene.

cu
Adrian

[1] Andrew is doing this

-- 

       "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: MODULE_MAINTAINER

[Stefan Richter]

Adrian Bunk wrote:
> Realistically, users should report problems with vendor kernels to the 
> vendor and problems with ftp.kernel.org kernels to either linux-kernel 
> or the kernel Bugzilla, and forwarding issues to the responsible people 
> (if any) should be done there [1].
> 
>> Rene.
> 
> cu
> Adrian
> 
> [1] Andrew is doing this

At bugzilla.kernel.org, driver maintainers can also watch the respective
subsystem maintainer's address or subsystem's meta address to get
notified when a bug is being filed under a subsystem.
-- 
Stefan Richter
-=====-=-=== -=-- --=-=
http://arcgraph.de/sr/

Re: MODULE_MAINTAINER

[Rene Herman]

On 04/04/2007 06:38 PM, Rene Herman wrote:

Rusty?

> On 04/04/2007 06:00 PM, Alan Cox wrote:
> 
>>> Given that people seem to agree that authorship information has no 
>>> place in the binary, that might actually be best.
>>
>> Authorship information is very useful in the binary, especially when you
>> have to get lawyers involved in explaining things to people.
> 
> Okay.
> 
>>> So, MODULE_AUTHOR be gone?
>>
>> Not if I have anything to do with it. Putting maintainer in is not a
>> bad idea but that assumes it gets maintained, the beauty of _AUTHOR
>> is that it's generally right and stays that way or approximately so.
> 
> Case in point; someone is working with me in private on a new "mitsumi" 
> legacy CD-ROM driver. He's authoring the actual driver and upto now I've 
> just been doing some peripheral module infrastructure work. Given that I 
> have the hardware to test the thing, I'll be the maintainer though.
> 
> Adding myself as a MODULE_AUTHOR would be largely incorrect and adding 
> myself as the _only_ MODULE_AUTHOR would be so factually incorrect I 
> wouldn't, even if only from a credits point of view. Yet I do want to 
> make sure people contact me, and not the MODULE_AUTHOR (which will 
> happen no matter the MAINTAINERS file).
> 
> Other cases-in-point; I've lately been rummaging through sound/isa a 
> bit. Nothing much copyrightable again but especially in those situations 
> where (some of the) original authors are no longer active, I do again 
> want people to contact me about them if needed. And all the "which one 
> of the three people listed here is maintaining this" is yet another.
> 
> MODULE_AUTHOR may be approximately right but especially with old drivers 
> it also has little relation with who's maintaining the thing.
> 
> If MODULE_AUTHOR stays, can I just have MODULE_MAINTAINER please? It 
> doesn't need to be added to drivers directly, it can just grow (and 
> being inside the code, I suppose it'll likely stay up to date better 
> than the MAINTAINERS file).

Rene.

Re: MODULE_MAINTAINER

[Rusty Russell]

On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote:
> On 04/04/2007 06:38 PM, Rene Herman wrote:
> 
> Rusty?

Valid points have been made on both sides.  I suggest:

#define MODULE_MAINTAINER(_maintainer) \
	MODULE_AUTHOR("(Maintained by) "_maintainer)

Cheers,
Rusty.

Re: MODULE_MAINTAINER

[Robert P. J. Day]

On Mon, 23 Apr 2007, Rusty Russell wrote:

> On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote:
> > On 04/04/2007 06:38 PM, Rene Herman wrote:
> >
> > Rusty?
>
> Valid points have been made on both sides.  I suggest:
>
> #define MODULE_MAINTAINER(_maintainer) \
> 	MODULE_AUTHOR("(Maintained by) "_maintainer)

why bring MODULE_AUTHOR into it?  just define it in terms of
MODULE_INFO:

#define MODULE_MAINTAINER(_m) MODULE_INFO(_m, "(Maintained by)"  \
	maintainer)

technically, the maintainer is not the same as the author so why
confuse the issue with an extra unnecessary macro expansion?

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: MODULE_MAINTAINER

[Robert P. J. Day]

On Mon, 23 Apr 2007, Robert P. J. Day wrote:

> On Mon, 23 Apr 2007, Rusty Russell wrote:
>
> > On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote:
> > > On 04/04/2007 06:38 PM, Rene Herman wrote:
> > >
> > > Rusty?
> >
> > Valid points have been made on both sides.  I suggest:
> >
> > #define MODULE_MAINTAINER(_maintainer) \
> > 	MODULE_AUTHOR("(Maintained by) "_maintainer)
>
> why bring MODULE_AUTHOR into it?  just define it in terms of
> MODULE_INFO:
>
> #define MODULE_MAINTAINER(_m) MODULE_INFO(_m, "(Maintained by)"  \
> 	maintainer)

whoops, the above is obviously syntactically incorrect, but you get
the idea regarding MODULE_INFO, right?

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: MODULE_MAINTAINER

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On 04/23/2007 01:52 PM, Robert P. J. Day wrote:

> On Mon, 23 Apr 2007, Rusty Russell wrote:

>> Valid points have been made on both sides.  I suggest:
>>
>> #define MODULE_MAINTAINER(_maintainer) \
>> 	MODULE_AUTHOR("(Maintained by) "_maintainer)
> 
> why bring MODULE_AUTHOR into it?  just define it in terms of
> MODULE_INFO:
> 
> #define MODULE_MAINTAINER(_m) MODULE_INFO(_m, "(Maintained by)"  \
> 	maintainer)
> 
> technically, the maintainer is not the same as the author so why
> confuse the issue with an extra unnecessary macro expansion?

Swap arguments to MODULE_INFO, but yes, other than the extra "(Maintained 
by)" that's what was originally submitted:

http://lkml.org/lkml/2007/4/4/170

If you're going to be using a "maintainer" tag anyway as both that and yours 
above does, the "(Maintained by)" becomes superfluous, so we're back at the 
original.

I must say I'm not particularly sure either why reusing MODULE_AUTHOR would 
be better if MODULE_AUTHOR also remains (as Alan Cox pointed out might be 
desirable for legal reasons if nothing else). As fas as I'm aware, the other 
trivial patch I posted to init-module-tools:

http://lkml.org/lkml/2007/4/4/171

is all that's needed to make it useful.

But, I also really only care about being able to add MODULE_MAINTAINER() to 
some drivers that have outlived their authors and from that viewpoint there 
is no difference, so if Rusty feels this is better, so be it.

Andrew, mind if I submit this to you?

===
Provide MODULE_MAINTAINER() as a convenient place to stick a name and email 
address both for drivers having multiple (current and non-current) authors 
and for when someone who wants to maintain a driver isn't so much an author.

Signed-off-by: Rene Herman <rene.herman@gmail.com>
===

Rene.


[-- Attachment #2: module_maintainer2.diff --]
[-- Type: text/plain, Size: 603 bytes --]

diff --git a/include/linux/module.h b/include/linux/module.h
index 10f771a..3c54774 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -128,6 +128,10 @@ extern struct module __this_module;
 /* Author, ideally of form NAME <EMAIL>[, NAME <EMAIL>]*[ and NAME <EMAIL>] */
 #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
   
+/* Maintainer, ideally of form NAME <EMAIL> */
+#define MODULE_MAINTAINER(_maintainer) \
+	MODULE_AUTHOR("(Maintained by) "_maintainer)
+
 /* What your module does. */
 #define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
 

Re: MODULE_MAINTAINER

[Andrew Morton]

On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <rene.herman@gmail.com> wrote:

> Provide MODULE_MAINTAINER() as a convenient place to stick a name and email 
> address both for drivers having multiple (current and non-current) authors 
> and for when someone who wants to maintain a driver isn't so much an author.
> 
> Signed-off-by: Rene Herman <rene.herman@gmail.com>
> ===
> 
> Rene.
> 
> 
> 
> [module_maintainer2.diff  text/plain (604B)]
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 10f771a..3c54774 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -128,6 +128,10 @@ extern struct module __this_module;
>  /* Author, ideally of form NAME <EMAIL>[, NAME <EMAIL>]*[ and NAME <EMAIL>] */
>  #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
>    
> +/* Maintainer, ideally of form NAME <EMAIL> */
> +#define MODULE_MAINTAINER(_maintainer) \
> +	MODULE_AUTHOR("(Maintained by) "_maintainer)
> +

I'm not sure we want to do this - that's what ./MAINTAINERS is for and we
end up having to maintain the same info in two places.

I actually use git-whatchanged if I'm unsure who to blame^Wask for help on
a particular piece of code.

An easy way of doing this is to go to
http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree
then drill down to the file and hit the "history" link.  That will tell you who
is *really* doing work on the particular code.

Re: MODULE_MAINTAINER

[Rusty Russell]

On Wed, 2007-04-25 at 18:18 -0700, Andrew Morton wrote:
> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <rene.herman@gmail.com> wrote:
> 
> > Provide MODULE_MAINTAINER() as a convenient place to stick a name and email 
> 
> I'm not sure we want to do this - that's what ./MAINTAINERS is for and we
> end up having to maintain the same info in two places.

I don't think MAINTAINERS should cover most modules.  But I don't really
mind.

Rusty.

Re: MODULE_MAINTAINER

[Rene Herman]

On 04/26/2007 03:18 AM, Andrew Morton wrote:

> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <rene.herman@gmail.com>
> wrote:
> 
>> Provide MODULE_MAINTAINER() as a convenient place to stick a name and
>> email address both for drivers having multiple (current and
>> non-current) authors and for when someone who wants to maintain a
>> driver isn't so much an author.

[ snip ]

> I'm not sure we want to do this - that's what ./MAINTAINERS is for and we
> end up having to maintain the same info in two places.

joe@user:~$ less ./MAINTAINERS
./MAINTAINERS: No such file or directory

MAINTAINERS is a developers thing, not users, yet a maintainer is someone 
who other than by developers wants to be contacted by users of a particular 
driver. Right now, a module exports a set of name and email addresses 
through the MODULE_AUTHOR tag but given multiple current and non-current 
authors, completely or largely orphaned drivers (I have a lot of junk PC 
hardware so I come across those relatively often) and people who might be 
interested in taking care of a driver but who do not consider themselves an 
author for (upto now) having done a s/, struct pt_regs// on it, that tag 
only confuses the issue of whom to contact.

And it in fact even does so when Joe does know about a MAINTAINERS file and 
does happen to have a kernel source tree lying around somewhere. With one 
set of addresses displayed prominently inside the sourcecode of the very 
driver and another one of in a MAINTAINERS file, the first one wins. Joe 
would have to be very new to Linux to trust something in the tree that's not 
actually compiled over something that is.

As the first response in this thread Cristoph Hellwig stated that 
MODULE_AUTHOR serves no purpose other than what MODULE_MAINTAINER would be 
serving. Others agreed and Adrian Bunk suggested deleting MODULE_AUTHOR 
outright.

That would actually also serve my purposes; if there's no MODULE_AUTHOR 
confusing the issue, I don't so much need a MODULE_MAINTAINER to fix it 
again. I believe having "modinfo" (optionally!) display a contact address 
for a driver might be a user advantage, but with all the wrong addresses 
gone, I don't really care deeply; MODULE_AUTHOR doesn't serve the purpose 
today and with it gone the user at least knows he needs to look elsewhere. 
MODULE_AUTHOR is also a credits issue but the information can be transferred 
to copyright headers. It would obviously also fix any possible maintenance 
issues.

Alan Cox believes that having author information embedded in the module 
serves a legal purpose though and objects to removal.

So, if MODULE_AUTHOR is going to stay I'd like to have MODULE_MAINTAINER to 
fix the message it sends. Some of it could be fixed by just deleting the 
email addresses from the MODULE_AUTHOR tag but that's probably not a good 
solution _either_. Those possible legal purposes are then the only 
conceivable use of the tag meaning that it should either be deleted outright 
if people don't agree on the legal angle or should retain the address as a 
contact point for legal issues/questions if people do.

The purpose I want MODULE_MAINTAINER for would not introduce any significant 
maintenance issues. It's not a "whole tree or nothing" thing. I want it for 
a few ISA crap drivers that have outlived their authors but list their names 
and email addresses in the source and binary through the MODULE_AUTHOR tag; 
  simply going around deleting MODULE_AUTHOR tags is not something us random 
kernelnewbie wannabee driver hackers can do. It's something "the community" 
could do but if noone is going to, we don't have a good way to override the 
information from MODULE_AUTHOR.

Rene.

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote:
> On 04/26/2007 03:18 AM, Andrew Morton wrote:
>
>> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <rene.herman@gmail.com>
>> wrote:
>>> Provide MODULE_MAINTAINER() as a convenient place to stick a name and
>>> email address both for drivers having multiple (current and
>>> non-current) authors and for when someone who wants to maintain a
>>> driver isn't so much an author.
>
> [ snip ]
>
>> I'm not sure we want to do this - that's what ./MAINTAINERS is for and we
>> end up having to maintain the same info in two places.
>
> joe@user:~$ less ./MAINTAINERS
> ./MAINTAINERS: No such file or directory
>
> MAINTAINERS is a developers thing, not users, yet a maintainer is someone 
> who other than by developers wants to be contacted by users of a particular 
> driver. Right now, a module exports a set of name and email addresses 
> through the MODULE_AUTHOR tag but given multiple current and non-current 
> authors, completely or largely orphaned drivers (I have a lot of junk PC 
> hardware so I come across those relatively often) and people who might be 
> interested in taking care of a driver but who do not consider themselves an 
> author for (upto now) having done a s/, struct pt_regs// on it, that tag 
> only confuses the issue of whom to contact.
>
> And it in fact even does so when Joe does know about a MAINTAINERS file and 
> does happen to have a kernel source tree lying around somewhere. With one 
> set of addresses displayed prominently inside the sourcecode of the very 
> driver and another one of in a MAINTAINERS file, the first one wins. Joe 
> would have to be very new to Linux to trust something in the tree that's 
> not actually compiled over something that is.
>
> As the first response in this thread Cristoph Hellwig stated that 
> MODULE_AUTHOR serves no purpose other than what MODULE_MAINTAINER would be 
> serving. Others agreed and Adrian Bunk suggested deleting MODULE_AUTHOR 
> outright.
>
> That would actually also serve my purposes; if there's no MODULE_AUTHOR 
> confusing the issue, I don't so much need a MODULE_MAINTAINER to fix it 
> again. I believe having "modinfo" (optionally!) display a contact address 
> for a driver might be a user advantage, but with all the wrong addresses 
> gone, I don't really care deeply; MODULE_AUTHOR doesn't serve the purpose 
> today and with it gone the user at least knows he needs to look elsewhere. 
> MODULE_AUTHOR is also a credits issue but the information can be 
> transferred to copyright headers. It would obviously also fix any possible 
> maintenance issues.
>
> Alan Cox believes that having author information embedded in the module 
> serves a legal purpose though and objects to removal.
>...

Let me try to summarize the points:
- you think MODULE_AUTHOR without MODULE_MAINTAINER confuses users
- Alan wants MODULE_AUTHOR to stay for easing showing authorship of code
  to people
- I (and others) think MODULE_MAINTAINER wouldn't make sense

Is there any good solution for this?
E.g. modinfo could be changed to no longer defaulting to show the author?

> Rene.

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: MODULE_MAINTAINER

[Rene Herman]

On 04/26/2007 03:54 PM, Adrian Bunk wrote:

> Let me try to summarize the points:
> - you think MODULE_AUTHOR without MODULE_MAINTAINER confuses users

Yes, and the frustration of composing lengthy emails to bouncing (or worse 
still, silent) email adresses is severe if you just decided to for once not 
shrug about it but submit a bugreport. If it happens to an address from 
MAINTAINERS (and an LKML savvy user) the address can at least be deleted but 
you can't delete a MODULE_AUTHOR tag.

Without something like a MODULE_MAINTAINER I have no way of saying "ignore 
those MODULE_AUTHORs please, I want the bugreport".

> - Alan wants MODULE_AUTHOR to stay for easing showing authorship of code
>   to people
> - I (and others) think MODULE_MAINTAINER wouldn't make sense

Had a few Ays as well. But note, since you suggested removing MODULE_AUTHOR 
I actually agree that made more sense. It's just that iff that can't happen, 
I feel I need a place to override MODULE_AUTHOR for the use that I'm 
interested in and which is acting as the contact for a driver.

> Is there any good solution for this?
> E.g. modinfo could be changed to no longer defaulting to show the author?

Tie Alan to his chair and take away his keyboard while we submit patches 
removing MODULE_AUTHOR? Or just apply a trivial two line, optional, non 
mandatory, patch introducing a MODULE_MAINTAINER? You pick... :-)

Rene.

Re: MODULE_MAINTAINER

[Alan Cox]

> Tie Alan to his chair and take away his keyboard while we submit patches 
> removing MODULE_AUTHOR? Or just apply a trivial two line, optional, non 
> mandatory, patch introducing a MODULE_MAINTAINER? You pick... :-)

MODULE_AUTHOR is extremely important for licensing enforcement. Removing
it should not be an option.

Alan

Re: MODULE_MAINTAINER

[Rene Herman]

On 04/26/2007 06:00 PM, Alan Cox wrote:

>> Tie Alan to his chair and take away his keyboard while we submit patches 
>> removing MODULE_AUTHOR? Or just apply a trivial two line, optional, non 
>> mandatory, patch introducing a MODULE_MAINTAINER? You pick... :-)
> 
> MODULE_AUTHOR is extremely important for licensing enforcement. Removing
> it should not be an option.

Yes, the "choice" was obviously in jest. If you say MODULE_AUTHOR must stay, 
so must it. As said, that just leaves me wanting a way to override it as a 
contact.

Rene.

Re: MODULE_MAINTAINER

[Randy Dunlap]

On Thu, 26 Apr 2007 15:54:26 +0200 Adrian Bunk wrote:

> On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote:
> > On 04/26/2007 03:18 AM, Andrew Morton wrote:
> >
> >> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <rene.herman@gmail.com>
> >> wrote:
> >>> Provide MODULE_MAINTAINER() as a convenient place to stick a name and
> >>> email address both for drivers having multiple (current and
> >>> non-current) authors and for when someone who wants to maintain a
> >>> driver isn't so much an author.
> >
> > [ snip ]
> >
> >> I'm not sure we want to do this - that's what ./MAINTAINERS is for and we
> >> end up having to maintain the same info in two places.
> >
> > joe@user:~$ less ./MAINTAINERS
> > ./MAINTAINERS: No such file or directory
> >
> > MAINTAINERS is a developers thing, not users, yet a maintainer is someone 
> > who other than by developers wants to be contacted by users of a particular 
> > driver. Right now, a module exports a set of name and email addresses 
> > through the MODULE_AUTHOR tag but given multiple current and non-current 
> > authors, completely or largely orphaned drivers (I have a lot of junk PC 
> > hardware so I come across those relatively often) and people who might be 
> > interested in taking care of a driver but who do not consider themselves an 
> > author for (upto now) having done a s/, struct pt_regs// on it, that tag 
> > only confuses the issue of whom to contact.
> >
> > And it in fact even does so when Joe does know about a MAINTAINERS file and 
> > does happen to have a kernel source tree lying around somewhere. With one 
> > set of addresses displayed prominently inside the sourcecode of the very 
> > driver and another one of in a MAINTAINERS file, the first one wins. Joe 
> > would have to be very new to Linux to trust something in the tree that's 
> > not actually compiled over something that is.
> >
> > As the first response in this thread Cristoph Hellwig stated that 
> > MODULE_AUTHOR serves no purpose other than what MODULE_MAINTAINER would be 
> > serving. Others agreed and Adrian Bunk suggested deleting MODULE_AUTHOR 
> > outright.
> >
> > That would actually also serve my purposes; if there's no MODULE_AUTHOR 
> > confusing the issue, I don't so much need a MODULE_MAINTAINER to fix it 
> > again. I believe having "modinfo" (optionally!) display a contact address 
> > for a driver might be a user advantage, but with all the wrong addresses 
> > gone, I don't really care deeply; MODULE_AUTHOR doesn't serve the purpose 
> > today and with it gone the user at least knows he needs to look elsewhere. 
> > MODULE_AUTHOR is also a credits issue but the information can be 
> > transferred to copyright headers. It would obviously also fix any possible 
> > maintenance issues.
> >
> > Alan Cox believes that having author information embedded in the module 
> > serves a legal purpose though and objects to removal.

Wouldn't a /* comment */ satisfy AUTHOR needs?

It gives deserved attribution and should serve legal purpose just as
well as a macro does (IANAL!).

IMO we want MAINTAINER info in the macro and in modinfo,
so I'm for removing MODULE_AUTHOR and just having MAINTAINER.


> >...
> 
> Let me try to summarize the points:
> - you think MODULE_AUTHOR without MODULE_MAINTAINER confuses users
> - Alan wants MODULE_AUTHOR to stay for easing showing authorship of code
>   to people
> - I (and others) think MODULE_MAINTAINER wouldn't make sense
> 
> Is there any good solution for this?
> E.g. modinfo could be changed to no longer defaulting to show the author?



---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Thu, Apr 26, 2007 at 08:41:43AM -0700, Randy Dunlap wrote:
> On Thu, 26 Apr 2007 15:54:26 +0200 Adrian Bunk wrote:
> 
> > On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote:
> > > On 04/26/2007 03:18 AM, Andrew Morton wrote:
> > >
> > >> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <rene.herman@gmail.com>
> > >> wrote:
> > >>> Provide MODULE_MAINTAINER() as a convenient place to stick a name and
> > >>> email address both for drivers having multiple (current and
> > >>> non-current) authors and for when someone who wants to maintain a
> > >>> driver isn't so much an author.
> > >
> > > [ snip ]
> > >
> > >> I'm not sure we want to do this - that's what ./MAINTAINERS is for and we
> > >> end up having to maintain the same info in two places.
> > >
> > > joe@user:~$ less ./MAINTAINERS
> > > ./MAINTAINERS: No such file or directory
> > >
> > > MAINTAINERS is a developers thing, not users, yet a maintainer is someone 
> > > who other than by developers wants to be contacted by users of a particular 
> > > driver. Right now, a module exports a set of name and email addresses 
> > > through the MODULE_AUTHOR tag but given multiple current and non-current 
> > > authors, completely or largely orphaned drivers (I have a lot of junk PC 
> > > hardware so I come across those relatively often) and people who might be 
> > > interested in taking care of a driver but who do not consider themselves an 
> > > author for (upto now) having done a s/, struct pt_regs// on it, that tag 
> > > only confuses the issue of whom to contact.
> > >
> > > And it in fact even does so when Joe does know about a MAINTAINERS file and 
> > > does happen to have a kernel source tree lying around somewhere. With one 
> > > set of addresses displayed prominently inside the sourcecode of the very 
> > > driver and another one of in a MAINTAINERS file, the first one wins. Joe 
> > > would have to be very new to Linux to trust something in the tree that's 
> > > not actually compiled over something that is.
> > >
> > > As the first response in this thread Cristoph Hellwig stated that 
> > > MODULE_AUTHOR serves no purpose other than what MODULE_MAINTAINER would be 
> > > serving. Others agreed and Adrian Bunk suggested deleting MODULE_AUTHOR 
> > > outright.
> > >
> > > That would actually also serve my purposes; if there's no MODULE_AUTHOR 
> > > confusing the issue, I don't so much need a MODULE_MAINTAINER to fix it 
> > > again. I believe having "modinfo" (optionally!) display a contact address 
> > > for a driver might be a user advantage, but with all the wrong addresses 
> > > gone, I don't really care deeply; MODULE_AUTHOR doesn't serve the purpose 
> > > today and with it gone the user at least knows he needs to look elsewhere. 
> > > MODULE_AUTHOR is also a credits issue but the information can be 
> > > transferred to copyright headers. It would obviously also fix any possible 
> > > maintenance issues.
> > >
> > > Alan Cox believes that having author information embedded in the module 
> > > serves a legal purpose though and objects to removal.
> 
> Wouldn't a /* comment */ satisfy AUTHOR needs?
> 
> It gives deserved attribution and should serve legal purpose just as
> well as a macro does (IANAL!).

Alan's opinion in [1] sounds reasonable (and I trust that he knows what 
he is talking about).

> IMO we want MAINTAINER info in the macro and in modinfo,
> so I'm for removing MODULE_AUTHOR and just having MAINTAINER.
>...

I don't think we want to expose maintainership information to users at 
all:
- duplicates information in MAINTAINERS
- maintainers sometimes disappear
- the 3 year old kernel of your distribution would contain 3 year old
  maintainership information

IMHO the default should be that users report problems with distribution 
kernels to their distribution and problems with ftp.kernel.org kernels 
to either linux-kernel or the kernel Bugzilla.

> ~Randy

cu
Adrian

[1] http://lkml.org/lkml/2007/4/4/260

-- 

       "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: MODULE_MAINTAINER

[Randy Dunlap]

On Thu, 26 Apr 2007 17:52:06 +0200 Adrian Bunk wrote:

> On Thu, Apr 26, 2007 at 08:41:43AM -0700, Randy Dunlap wrote:
> > On Thu, 26 Apr 2007 15:54:26 +0200 Adrian Bunk wrote:
> > 
> > > On Thu, Apr 26, 2007 at 12:41:41PM +0200, Rene Herman wrote:
> > > > On 04/26/2007 03:18 AM, Andrew Morton wrote:
> > > >
> > > >> On Mon, 23 Apr 2007 14:32:36 +0200 Rene Herman <rene.herman@gmail.com>
> > > >> wrote:
> > > >>> Provide MODULE_MAINTAINER() as a convenient place to stick a name and
> > > >>> email address both for drivers having multiple (current and
> > > >>> non-current) authors and for when someone who wants to maintain a
> > > >>> driver isn't so much an author.
> > > >
> > > > [ snip ]
> > > >
> > > >> I'm not sure we want to do this - that's what ./MAINTAINERS is for and we
> > > >> end up having to maintain the same info in two places.
> > > >
> > > > joe@user:~$ less ./MAINTAINERS
> > > > ./MAINTAINERS: No such file or directory
> > > >
> > > > MAINTAINERS is a developers thing, not users, yet a maintainer is someone 
> > > > who other than by developers wants to be contacted by users of a particular 
> > > > driver. Right now, a module exports a set of name and email addresses 
> > > > through the MODULE_AUTHOR tag but given multiple current and non-current 
> > > > authors, completely or largely orphaned drivers (I have a lot of junk PC 
> > > > hardware so I come across those relatively often) and people who might be 
> > > > interested in taking care of a driver but who do not consider themselves an 
> > > > author for (upto now) having done a s/, struct pt_regs// on it, that tag 
> > > > only confuses the issue of whom to contact.
> > > >
> > > > And it in fact even does so when Joe does know about a MAINTAINERS file and 
> > > > does happen to have a kernel source tree lying around somewhere. With one 
> > > > set of addresses displayed prominently inside the sourcecode of the very 
> > > > driver and another one of in a MAINTAINERS file, the first one wins. Joe 
> > > > would have to be very new to Linux to trust something in the tree that's 
> > > > not actually compiled over something that is.
> > > >
> > > > As the first response in this thread Cristoph Hellwig stated that 
> > > > MODULE_AUTHOR serves no purpose other than what MODULE_MAINTAINER would be 
> > > > serving. Others agreed and Adrian Bunk suggested deleting MODULE_AUTHOR 
> > > > outright.
> > > >
> > > > That would actually also serve my purposes; if there's no MODULE_AUTHOR 
> > > > confusing the issue, I don't so much need a MODULE_MAINTAINER to fix it 
> > > > again. I believe having "modinfo" (optionally!) display a contact address 
> > > > for a driver might be a user advantage, but with all the wrong addresses 
> > > > gone, I don't really care deeply; MODULE_AUTHOR doesn't serve the purpose 
> > > > today and with it gone the user at least knows he needs to look elsewhere. 
> > > > MODULE_AUTHOR is also a credits issue but the information can be 
> > > > transferred to copyright headers. It would obviously also fix any possible 
> > > > maintenance issues.
> > > >
> > > > Alan Cox believes that having author information embedded in the module 
> > > > serves a legal purpose though and objects to removal.
> > 
> > Wouldn't a /* comment */ satisfy AUTHOR needs?
> > 
> > It gives deserved attribution and should serve legal purpose just as
> > well as a macro does (IANAL!).
> 
> Alan's opinion in [1] sounds reasonable (and I trust that he knows what 
> he is talking about).

OK, I see.

> > IMO we want MAINTAINER info in the macro and in modinfo,
> > so I'm for removing MODULE_AUTHOR and just having MAINTAINER.
> >...
> 
> I don't think we want to expose maintainership information to users at 
> all:
> - duplicates information in MAINTAINERS
> - maintainers sometimes disappear
> - the 3 year old kernel of your distribution would contain 3 year old
>   maintainership information
> 
> IMHO the default should be that users report problems with distribution 
> kernels to their distribution and problems with ftp.kernel.org kernels 
> to either linux-kernel or the kernel Bugzilla.

s/linux-kernel/the appropriate mailing list/ please :)

so looks to me like we maintain the status quo.

> > ~Randy
> 
> cu
> Adrian
> 
> [1] http://lkml.org/lkml/2007/4/4/260


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Thu, Apr 26, 2007 at 09:44:27AM -0700, Randy Dunlap wrote:
>...
> > IMHO the default should be that users report problems with distribution 
> > kernels to their distribution and problems with ftp.kernel.org kernels 
> > to either linux-kernel or the kernel Bugzilla.
> 
> s/linux-kernel/the appropriate mailing list/ please :)
>...

Yes, in an ideal world.

But a user reporting an Oops might not even know where the problem lies.

And a user reporting a networking bug to linux-kernel hasn't really done 
any mistake. Forwarding bugs to the right people (as Andrew does and I'm 
sometimes doing) is actually an easy part of bug handling.

> ~Randy

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: MODULE_MAINTAINER

[Krzysztof Halasa]

Adrian Bunk <bunk@stusta.de> writes:

> I don't think we want to expose maintainership information to users at 
> all:
> - duplicates information in MAINTAINERS
> - maintainers sometimes disappear
> - the 3 year old kernel of your distribution would contain 3 year old
>   maintainership information

Right. Summary: adding maintainer info to source code and/or
compiled modules doesn't seem to make any sense.

> IMHO the default should be that users report problems with distribution 
> kernels to their distribution and problems with ftp.kernel.org kernels 
> to either linux-kernel or the kernel Bugzilla.

Yep. But it's really easy to miss something in lkml and/or in
more specific lists, and the Bugzilla isn't email. That means
we need a WWW-browseable database, with:
a) maintainers registrations with a simple email verification or
   something like that
b) possibility for registered people to declare they now maintain
   (or not) specific portions of the kernel
c) possibility for anyone to retrieve this information.

Other options?
-- 
Krzysztof Halasa

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Thu, Apr 26, 2007 at 09:37:59PM +0200, Krzysztof Halasa wrote:
> Adrian Bunk <bunk@stusta.de> writes:
>...
> > IMHO the default should be that users report problems with distribution 
> > kernels to their distribution and problems with ftp.kernel.org kernels 
> > to either linux-kernel or the kernel Bugzilla.
> 
> Yep. But it's really easy to miss something in lkml and/or in
> more specific lists, and the Bugzilla isn't email. That means
> we need a WWW-browseable database, with:
> a) maintainers registrations with a simple email verification or
>    something like that
> b) possibility for registered people to declare they now maintain
>    (or not) specific portions of the kernel
> c) possibility for anyone to retrieve this information.
> 
> Other options?

What exactly is missing that the kernel Bugzilla doesn't already offer?

> Krzysztof Halasa

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: MODULE_MAINTAINER

[Krzysztof Halasa]

Adrian Bunk <bunk@stusta.de> writes:

> What exactly is missing that the kernel Bugzilla doesn't already offer?

Basically... unless I'm mistaken, nothing of the sort exists there.

Bugzilla is a database of bugs. What is needed is a database of
people, mailing lists and some network resources.

How do I easily retrieve maintainer's email address for a given
subsystem from Bugzilla?
-- 
Krzysztof Halasa

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Thu, Apr 26, 2007 at 10:02:35PM +0200, Krzysztof Halasa wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> 
> > What exactly is missing that the kernel Bugzilla doesn't already offer?
> 
> Basically... unless I'm mistaken, nothing of the sort exists there.
> 
> Bugzilla is a database of bugs. What is needed is a database of
> people, mailing lists and some network resources.
> 
> How do I easily retrieve maintainer's email address for a given
> subsystem from Bugzilla?

Ah, now I get what you want.

You only get this information from MAINTAINERS plus knowledge who 
recently touched which code (git helps with the latter).

The problem with such a database would be the same as with the 
MAINTAINERS file: The information becomes outdated, and someone has to 
maintain it.

Sending a patch against MAINTAINERS is easy - I don't see a 
WWW-browseable database being in any respect better than the 
MAINTAINERS file.

> Krzysztof Halasa

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: MODULE_MAINTAINER

[Krzysztof Halasa]

Adrian Bunk <bunk@stusta.de> writes:

> The problem with such a database would be the same as with the 
> MAINTAINERS file: The information becomes outdated, and someone has to 
> maintain it.

Sure, I can easily grep .../linux-current/MAINTAINERS. But I think the
whole problem is with people who don't have current sources.
-- 
Krzysztof Halasa

Re: MODULE_MAINTAINER

[Adrian Bunk]

On Thu, Apr 26, 2007 at 11:51:29PM +0200, Krzysztof Halasa wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> 
> > The problem with such a database would be the same as with the 
> > MAINTAINERS file: The information becomes outdated, and someone has to 
> > maintain it.
> 
> Sure, I can easily grep .../linux-current/MAINTAINERS. But I think the
> whole problem is with people who don't have current sources.

No, even MAINTAINERS in the latest sources always contains outdated 
entries and lacks information.

If you think "no current sources" is a problem that should be solved, 
the solution would simply be a link to [1].

> Krzysztof Halasa

cu
Adrian

[1] http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=MAINTAINERS;hb=HEAD

-- 

       "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: MODULE_MAINTAINER

[Krzysztof Halasa]

Adrian Bunk <bunk@stusta.de> writes:

> No, even MAINTAINERS in the latest sources always contains outdated 
> entries and lacks information.

Sure, but that can't be corrected using technical meanings.

> If you think "no current sources" is a problem that should be solved, 
> the solution would simply be a link to [1].

> [1] http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=MAINTAINERS;hb=HEAD

Well, the most simple solutions are sometimes quite good.
-- 
Krzysztof Halasa

Re: MODULE_MAINTAINER

[Rene Herman]

On 04/26/2007 10:24 PM, Adrian Bunk wrote:

> The problem with such a database would be the same as with the 
> MAINTAINERS file: The information becomes outdated, and someone has to 
> maintain it.
> 
> Sending a patch against MAINTAINERS is easy - I don't see a 
> WWW-browseable database being in any respect better than the MAINTAINERS
> file.

Well, in fact, the database could _be_ (a parsed version of) the current 
MAINTAINERS file; it's already in a strict, parseable format. I know that 
MAINTAINERS itself is not very good at staying up to date, but making more 
intensive use of it like that might in fact improve that...

Being able to have "modinfo module" then point at a specific link would 
require a bit more though. It could be agreed upon to, say, have a module 
that the kernel installs as

	/lib/modules/$(uname -r)/kernel/drivers/cdrom/mitsumi.ko

have a maintainer page at

	http://www.kernel.org/maintainer/driver/cdrom/mitsumi.html

but to generate that page, the maintainer file would then need to grow a way 
to associate the "MITSUMI CDROM DRIVER" entry (don't bother, it's not there) 
in the MAINTAINERS file with that page (and simply listing that install path 
in the entry isn't good -- I believe you would wan't to pin down a structure 
like that).

Anyways -- might all also be a bit of overkill anyway. If I can get those 
email adresses from MODULE_AUTHOR out of the way, I'm mostly happy.

Rene.

Re: MODULE_MAINTAINER

[Rene Herman]

On 04/26/2007 09:43 PM, Adrian Bunk wrote:

> What exactly is missing that the kernel Bugzilla doesn't already offer?

Users?

Rene.

Re: MODULE_MAINTAINER

[Gene Heskett]

On Thursday 26 April 2007, Rene Herman wrote:
>On 04/26/2007 09:43 PM, Adrian Bunk wrote:
>> What exactly is missing that the kernel Bugzilla doesn't already offer?
>
>Users?

That is the best answer of all, and I've stated my objections to that very 
nearly worthless utility before.  And that is exactly why it doesn't 
have "Users".  I have never, ever gone to bugzilla without killing well over 
an hour convincing it that yes, I really want DO to enter a bug report, not 
search for an old one.  Let me simply say that such and such doesn't work, 
attach the dmesg (or whatever) snip to show how it failed, and get on with 
it.  Wasting 2 hours crawling around looking for loopholes in the fence so I 
can wrap the report around a rock and throw it over?  That, and 30" of rain 
will raise 180 bushels to the acre where I come from...

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Statistics means never having to say you're certain.

Re: MODULE_MAINTAINER

[Stefan Richter]

Gene Heskett wrote:
> On Thursday 26 April 2007, Rene Herman wrote:
>>On 04/26/2007 09:43 PM, Adrian Bunk wrote:
>>> What exactly is missing that the kernel Bugzilla doesn't already offer?
>>
>>Users?
> 
> That is the best answer of all, and I've stated my objections to that very 
> nearly worthless utility before.  And that is exactly why it doesn't 
> have "Users".  I have never, ever gone to bugzilla without killing well over 
> an hour convincing it that yes, I really want DO to enter a bug report, not 
> search for an old one.  Let me simply say that such and such doesn't work, 
> attach the dmesg (or whatever) snip to show how it failed, and get on with 
> it.
[...]

Of course it is polite (and more or less expected from reporters,
independently of whether bugzilla or a mailinglist or personal e-mail is
used for a report) to search for similar reports and join them.
However, it doesn't stop there --- a bugzilla entry into which a lot of
different bugs are entered (because the reporters mistook them for the
same or didn't realize they face a number of separate problems) becomes
hard to handle for maintainers/ developers.

So, it is actually easier after all to have users create *duplicate*
bugs and then simply mark them as such once identified.  Bugzilla
directly supports tracking of duplicates while my mail user agent
doesn't.  (Some advanced MUAs might do, by tagging or the like.  But
that would only be visible to myself.)

As subsystem maintainer, I am actively using kernel.org's bugzilla and I
am polling more or less (mostly: /less/) frequently some distributor
bugzillas.  Here are my experiences:

  - I can't work without kernel.org's bugzilla simply because the
    average bug fixing rate of "my" subsystem is so slow.  I personally
    need a tracker better than some yellow sticky notes or whatever, and
    I chose kernel.org's bugzilla for it.

    That's one reason why I once and again ask people who report bugs at
    the -devel or -user mailinglist to enter their bug into bugzilla.
    But often I request this only after an initial conversation with the
    reporter, i.e. after the issue was already clarified a bit.  Side
    effects are that the effort of the user to enter the report becomes
    minimal (or even zero if I do it myself instead), and that the new
    entry is already rather qualified.

    Actually, a good deal of "my" currently unresolved bugs at
    bugzilla.kernel.org were entered by myself.  Some of those bugs are
    behind-the-scene bugs though which only indirectly affect endusers,
    thus wouldn't have reported by them anyway.

  - Using distributor's bugzillas is a mixed bag.  By nature, it takes
    more effort for kernel maintainers because linux-kernel is only one
    among a huge number of programs tracked in these bugzillas.

    There were times were I was able to get a lot of highly useful
    reports out of one particular bugzilla; and I name it here because
    its admins and users did such a great job IME: Redhat's bugzilla.
    Many of the bug entries there were highly focused and qualified and
    up-to-date, and some helped to get to bugfixes soon.  This positive
    experience somewhat diminished lately after the more prominent bugs
    were fixed.

    At other distributor bugzillas, the usually encountered difficulties
    besides the broad scope of their trackers were, in no particular
    order:
        - Lack of detail in bug descriptions,
        - many loosely related or unrelated bugs under the same ticket,
        - difficulties to work with the reporters to get more
          diagnostics (for varying reasons),
        - long delay between upstream release of regressions and
          report of regressions by distribution users,
        - my lacking polling frequency, being caused by and at the same
          time amplifying these other difficulties.

So, bugzilla.kernel.org and to a certain degree distributors' bugzillas
are valuable to me.  Still, switching between bugzilla and mailinglist
sometimes becomes awkward, IME in a similar way like switching between
mailinglist and personal e-mail.  Also, "my" subsystem (ieee1394) almost
doesn't have to deal anymore with new development, neither on the kernel
side nor as far as available hardware is concerned.  Therefore my
findings certainly do not reflect what other subsystem maintainers are
facing.

Back to MODULE_MAINTAINER and what Adrian said about where to report bugs:

>From the maintainer's point of view, my personal preference for bug
reports about "my" subsystem is, in descending order:
  - The -devel or -user mailinglist (but often in combination with
    bugzilla),
  - bugzilla,
  - ...?,
  - personal e-mail. (Just don't do it.)
But I do understand why the opener of this thread preferred personal
e-mail; he has explained it multiple times now.  He has valid points,
although they don't apply to by far most of the kernel subsystems.
-- 
Stefan Richter
-=====-=-=== -=-- ==-==
http://arcgraph.de/sr/

Re: MODULE_MAINTAINER

[Rene Herman]

On 04/26/2007 05:52 PM, Adrian Bunk wrote:

> I don't think we want to expose maintainership information to users at 
> all:

With the point you make about old installed kernel modules having outdated 
information forever you've in fact convinced me that MODULE_MAINTAINER is 
not a good idea. If I decide after some time that I no longer want to be a 
maintainer anymore, I can delete the MODULE_MAINTAINER and/or the entry in 
MAINTAINERS in the current kernel, but I could be getting mail for a long 
time still through old installs.

The problem I still have is that we _do_ expose authorship information, 
generally complete with (an) email address(es), which is the only address 
available from the binary and which is displayed on every invocation of the 
user tool "modinfo". Proper contact information may rather be available from 
a text file off in a source tree somewhere instead, but this information is 
ofcourse going to remain being interpreted as such however one may feel 
about it.

Deleting authorship information can't happen for legal reasons. Not in the 
global "delete them all" sense but also not in a local sense; a maintainer 
doesn't have the right to delete a MODULE_AUTHOR tag but not being able to 
additionally supply contact information _alongside_ that information then 
leaves the confusing message the tag sends as is.

Deleting the email addresses from the MODULE_AUTHOR tag would go some ways 
to fix it; it's then at least clearer that the author is not being displayed 
as a general contact for the driver. It may on the other hand want to remain 
as a legal contact and I only know of "modinfo" as a normal way of listing 
the tags, so even a very minimal solution such as having modinfo supress the 
author tag, or even just any email address in it, would be good enough.

Rene.

Re: MODULE_MAINTAINER

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 1709 bytes --]

On 04/27/2007 12:03 AM, Rene Herman wrote:

> With the point you make about old installed kernel modules having 
> outdated information forever you've in fact convinced me that 
> MODULE_MAINTAINER is not a good idea.

[ ... ]

> Deleting the email addresses from the MODULE_AUTHOR tag would go some 
> ways to fix it; it's then at least clearer that the author is not being 
> displayed as a general contact for the driver. It may on the other hand 
> want to remain as a legal contact and I only know of "modinfo" as a 
> normal way of listing the tags, so even a very minimal solution such as 
> having modinfo supress the author tag, or even just any email address in
> it, would be good enough.

Ie, something like the attached minimal patch to modinfo that just supresses 
the author= tag from the default output; the information is still available 
from modinfo -a.

However. Looking at the MODULE_AUTHOR tags in the tree:

rene@7ixe4:~/src/linux/local$ grep -r MODULE_AUTHOR * | wc -l
2211

more than half of them already don't provide an email address:

rene@7ixe4:~/src/linux/local$ grep -r "MODULE_AUTHOR(.*<.*>.*)" * | wc -l
1088

Alan is one of the people using just MODULE_AUTHOR("Alan Cox") without an 
address. Given that the email address is all that I want to supress; how 
about just deleting that instead?

I'd prefer that; unlike the name, the adress is information that can get 
outdated and moreover, removing the address not only from the modinfo output 
but from the source directly means it can't be mistaken for a contact 
address there either.

Comments? Objections? If none, I'll start submitting patches removing email 
addresses from the MODULE_AUTHOR tags in the tree.

Rene.


[-- Attachment #2: modinfo_author.diff --]
[-- Type: text/plain, Size: 381 bytes --]

--- module-init-tools-3.3-pre1/modinfo.c.orig	2007-04-04 12:54:19.000000000 +0200
+++ module-init-tools-3.3-pre1/modinfo.c	2007-04-27 22:41:54.000000000 +0200
@@ -167,6 +167,9 @@
 	for (; info; info = next_string(info, &size)) {
 		char *eq, *colon;
 
+		if (strstarts(info, "author="))
+			continue;
+
 		/* We expect this in parm and parmtype. */
 		colon = strchr(info, ':');
 

Re: MODULE_MAINTAINER

[Krzysztof Halasa]

Rene Herman <rene.herman@gmail.com> writes:

[MODULE_AUTHOR]

> Given that the email address is all that I want to
> supress; how about just deleting that instead?

Makes sense at least WRT the "problematic" modules.

include/linux/module.h says:

/* Author, ideally of form NAME <EMAIL>[, NAME <EMAIL>]*[ and NAME <EMAIL>] */
#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)

I think we should get rid of the "EMAIL" comments:

/* Author, ideally of form FULL NAME [, FULL NAME ]*[ and FULL NAME] */
#define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)


I'd rather let the respective maintainers/authors take care of "their"
MODULE_AUTHOR entries (though the removal seems sane for me personally).

> I'd prefer that; unlike the name, the adress is information that can
> get outdated

Right

> and moreover, removing the address not only from the
> modinfo output but from the source directly means it can't be mistaken
> for a contact address there either.

Sure.
-- 
Krzysztof Halasa

Re: MODULE_MAINTAINER

[Rusty Russell]

On Mon, 2007-04-23 at 07:52 -0400, Robert P. J. Day wrote:
> On Mon, 23 Apr 2007, Rusty Russell wrote:
> 
> > On Mon, 2007-04-23 at 11:33 +0200, Rene Herman wrote:
> > > On 04/04/2007 06:38 PM, Rene Herman wrote:
> > >
> > > Rusty?
> >
> > Valid points have been made on both sides.  I suggest:
> >
> > #define MODULE_MAINTAINER(_maintainer) \
> > 	MODULE_AUTHOR("(Maintained by) "_maintainer)
> 
> why bring MODULE_AUTHOR into it?  just define it in terms of
> MODULE_INFO:

Because author is an established field.  People might well search for
it.  This is fairly clear, and assuming that the maintainer has actually
done any maintenance, they're an author too.

Rusty.