All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Rene Herman <rene.herman@gmail.com>,
	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 17:52:06 +0200	[thread overview]
Message-ID: <20070426155205.GN3468@stusta.de> (raw)
In-Reply-To: <20070426084143.1d973c71.randy.dunlap@oracle.com>

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


  reply	other threads:[~2007-04-26 15:51 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                         ` 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                             ` Adrian Bunk [this message]
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=20070426155205.GN3468@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=randy.dunlap@oracle.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.