[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 04 Apr 2007 17:50:59 +0200
From: Rene Herman <rene.herman@...il.com>
To: Adrian Bunk <bunk@...sta.de>
CC: Marcel Holtmann <marcel@...tmann.org>,
Christoph Hellwig <hch@...radead.org>,
Rusty Russell <rusty@...tcorp.com.au>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: MODULE_MAINTAINER
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists