From: Rene Herman <rene.herman@gmail.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
bunk@stusta.de, randy.dunlap@oracle.com,
akpm@linux-foundation.org, rpjday@mindspring.com,
marcel@holtmann.org, hch@infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] module_author: don't advice putting in an email address
Date: Fri, 11 May 2007 19:21:59 +0200 [thread overview]
Message-ID: <4644A637.1060507@gmail.com> (raw)
In-Reply-To: <20070511154009.50c8bae0@the-village.bc.nu>
On 05/11/2007 04:40 PM, Alan Cox wrote:
>> But it's not a style issue. It's solving a problem. The adresses from this
>> tag are the only addresses available from the binary and as such are
>> mistaken for maintainer/general contact addresses which they often are not.
>
> Which is why you want MODULE_MAINTAINER()
Right. Or want_ed_ at least.
>> contacted for the driver. Giving that MODULE_MAINTAINER was concluded to not
>> be a good idea
>
> Not my fault, not my problem, take it back up with the objectors
The thing is, Adrian Bunk had a valid argument against it and it's one of
the arguments that exist against MODULE_AUTHOR as well; the address would
live on "forever" as part of Linux installs.
So say I'm maintaining driver foo. Then the dog eats my foo and I can't
maintain it anymore since I can't test; off goes a patch removing
MODULE_MAINTAINER from the source and/or the MAINTAINERS file but I can't do
anything about all the existing installs that proudly announce my address as
a contact for foo. The way I _can_ do something about existing installs is
to not make people believe there's a maintainer contact address there in the
first place so that people know they need to look elsewhere.
Now, unlike Adrian (it seems) I'm not actually all that worried about the
"forever" bit. People with old Linux installs around should quite possibly
not be overly worried about so I'm still not against MODULE_MAINTAINER but
it is a valid argument. And no, it's not the same as "the source tree on the
user's box". Why would there even be any such thing?
> The author also can't update the kernel rpm packages provided by the
> distibutor where 99.99% of the users get their data.
Right. So let's stop putting in confusing data in the first place. This is
what the patch that you objected to advised (<-- s!).
> I have no problem with people using name only, or name and email. Its
> not my problem what they use.
Your argument is inconsistent. The current comment says:
/* Author, ideally of form NAME <EMAIL>[, NAME <EMAIL>]*[ and NAME <EMAIL>]
After my trivial patch, it says:
/* Author, ideally of form NAME[, NAME]*[ and NAME] */
So what do you find _better_ about the first form? I've been going on about
the problems of it only one of which is email adresses geting outdated
(which happens for multiple reasons; owner graduating, ISP mergers, dog
eating owner's foo, owner dying, dog dying and owner getting so depressed he
just can't handle it all anymore, what have you) and as such putting them
into the binary is not something to generally advise.
>> Finally, at the very, very least the advice to add more future problems
>> should be killed and that's the only thing _this_ particular patch does.
>
> Adding new drivers causes future problems, lets stop that too ?
That's being argumentative just for the heck of it. (N+1) future problems
are not better than N future problems.
The patch as submitted stands. The advice of putting in an email address is
generally bad advice. Stop giving generally bad advice.
Rene.
next prev parent reply other threads:[~2007-05-11 17:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-11 0:50 [PATCH] module_author: don't advice putting in an email address Rene Herman
2007-05-11 10:46 ` Alan Cox
2007-05-11 11:42 ` John Anthony Kazos Jr.
2007-05-11 20:50 ` Rene Herman
2007-05-11 21:18 ` Adrian Bunk
2007-05-11 21:35 ` Alan Cox
2007-05-12 7:14 ` Adrian Bunk
2007-05-12 12:15 ` Alan Cox
2007-05-12 12:38 ` Adrian Bunk
2007-05-11 14:16 ` Rene Herman
2007-05-11 14:40 ` Alan Cox
2007-05-11 17:21 ` Rene Herman [this message]
2007-05-11 23:23 ` Krzysztof Halasa
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=4644A637.1060507@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=randy.dunlap@oracle.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