Message-Id: <20070426084143.1d973c71.randy.dunlap@oracle.com>
Date:	Thu, 26 Apr 2007 08:41:43 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Adrian Bunk <bunk@...sta.de>
Cc:	Rene Herman <rene.herman@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Robert P. J. Day" <rpjday@...dspring.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Marcel Holtmann <marcel@...tmann.org>,
	Christoph Hellwig <hch@...radead.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: MODULE_MAINTAINER

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@...il.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@...r:~$ 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 ***
-
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