public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rene Herman <rene.herman@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Robert P. J. Day" <rpjday@mindspring.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>, Adrian Bunk <bunk@stusta.de>,
	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 12:41:41 +0200	[thread overview]
Message-ID: <463081E5.5010306@gmail.com> (raw)
In-Reply-To: <20070425181856.42fcfeb4.akpm@linux-foundation.org>

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.


  parent reply	other threads:[~2007-04-26 10:44 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                       ` Rene Herman [this message]
2007-04-26 13:54                         ` MODULE_MAINTAINER Adrian Bunk
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=463081E5.5010306@gmail.com \
    --to=rene.herman@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bunk@stusta.de \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --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