From: Adrian Bunk <bunk@stusta.de>
To: Rene Herman <rene.herman@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Robert P. J. Day" <rpjday@mindspring.com>,
Rusty Russell <rusty@rustcorp.com.au>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Marcel Holtmann <marcel@holtmann.org>,
Christoph Hellwig <hch@infradead.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: MODULE_MAINTAINER
Date: Thu, 26 Apr 2007 15:54:26 +0200 [thread overview]
Message-ID: <20070426135426.GM3468@stusta.de> (raw)
In-Reply-To: <463081E5.5010306@gmail.com>
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
next prev parent reply other threads:[~2007-04-26 13:54 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-04 11:26 MODULE_MAINTAINER Rene Herman
2007-04-04 11:29 ` MODULE_MAINTAINER Rene Herman
2007-04-04 12:33 ` MODULE_MAINTAINER Christoph Hellwig
2007-04-04 13:02 ` MODULE_MAINTAINER Rene Herman
2007-04-04 14:57 ` MODULE_MAINTAINER Adrian Bunk
2007-04-04 16:33 ` MODULE_MAINTAINER Stefan Richter
2007-04-04 16:38 ` MODULE_MAINTAINER Adrian Bunk
2007-04-04 16:45 ` MODULE_MAINTAINER Stefan Richter
2007-04-04 14:48 ` MODULE_MAINTAINER Marcel Holtmann
2007-04-04 15:02 ` MODULE_MAINTAINER Adrian Bunk
2007-04-04 15:50 ` MODULE_MAINTAINER Rene Herman
2007-04-04 16:00 ` MODULE_MAINTAINER Alan Cox
2007-04-04 16:06 ` MODULE_MAINTAINER Marcel Holtmann
2007-04-04 16:38 ` MODULE_MAINTAINER Rene Herman
2007-04-04 17:00 ` MODULE_MAINTAINER Takashi Iwai
2007-04-04 17:48 ` MODULE_MAINTAINER Adrian Bunk
2007-04-04 18:01 ` MODULE_MAINTAINER Rene Herman
2007-04-04 19:12 ` MODULE_MAINTAINER Adrian Bunk
2007-04-05 0:08 ` MODULE_MAINTAINER Stefan Richter
2007-04-23 9:33 ` MODULE_MAINTAINER Rene Herman
2007-04-23 11:24 ` MODULE_MAINTAINER Rusty Russell
2007-04-23 11:52 ` MODULE_MAINTAINER Robert P. J. Day
2007-04-23 12:00 ` MODULE_MAINTAINER Robert P. J. Day
2007-04-23 12:32 ` MODULE_MAINTAINER Rene Herman
2007-04-26 1:18 ` MODULE_MAINTAINER Andrew Morton
2007-04-26 10:03 ` MODULE_MAINTAINER Rusty Russell
2007-04-26 10:41 ` MODULE_MAINTAINER Rene Herman
2007-04-26 13:54 ` Adrian Bunk [this message]
2007-04-26 14:55 ` MODULE_MAINTAINER Rene Herman
2007-04-26 16:00 ` MODULE_MAINTAINER Alan Cox
2007-04-26 16:45 ` MODULE_MAINTAINER Rene Herman
2007-04-26 15:41 ` MODULE_MAINTAINER Randy Dunlap
2007-04-26 15:52 ` MODULE_MAINTAINER Adrian Bunk
2007-04-26 16:44 ` MODULE_MAINTAINER Randy Dunlap
2007-04-26 17:12 ` MODULE_MAINTAINER Adrian Bunk
2007-04-26 19:37 ` MODULE_MAINTAINER Krzysztof Halasa
2007-04-26 19:43 ` MODULE_MAINTAINER Adrian Bunk
2007-04-26 20:02 ` MODULE_MAINTAINER Krzysztof Halasa
2007-04-26 20:24 ` MODULE_MAINTAINER Adrian Bunk
2007-04-26 21:51 ` MODULE_MAINTAINER Krzysztof Halasa
2007-04-26 22:01 ` MODULE_MAINTAINER Adrian Bunk
2007-04-26 22:07 ` MODULE_MAINTAINER Krzysztof Halasa
2007-04-26 22:28 ` MODULE_MAINTAINER Rene Herman
2007-04-26 20:11 ` MODULE_MAINTAINER Rene Herman
2007-04-26 22:24 ` MODULE_MAINTAINER Gene Heskett
2007-04-27 9:06 ` MODULE_MAINTAINER Stefan Richter
2007-04-26 22:03 ` MODULE_MAINTAINER Rene Herman
2007-04-27 21:06 ` MODULE_MAINTAINER Rene Herman
2007-04-28 21:03 ` MODULE_MAINTAINER Krzysztof Halasa
2007-04-23 23:46 ` MODULE_MAINTAINER Rusty Russell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070426135426.GM3468@stusta.de \
--to=bunk@stusta.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcel@holtmann.org \
--cc=rene.herman@gmail.com \
--cc=rpjday@mindspring.com \
--cc=rusty@rustcorp.com.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox