On Thu, 26 Apr 2007 17:52:06 +0200 Adrian Bunk wrote:
> 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 <[email protected]>
> > > >> 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).
OK, I see.
> > 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.
s/linux-kernel/the appropriate mailing list/ please :)
so looks to me like we maintain the status quo.
> > ~Randy
>
> cu
> Adrian
>
> [1] http://lkml.org/lkml/2007/4/4/260
---
~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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
