Re: [PATCH] module_author: don't advice putting in an email address

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Still here
    ... but really it was only a couple of days of feeling not-so-good, then it got okay again. ... After the first 2 nights of very little sleep punctuated by extremely detailed dreams, I went back to the pharmacist for more advice. ... then I can always put on a patch. ... than 6 weeks to get me through one certain upcoming vulnerable event on ...
    (alt.support.stop-smoking)
  • Re: [PATCH 2.6.20-rc5 1/1] MM: enhance Linux swap subsystem
    ... Please stop resending this patch until you can attend to the advice ... Another piece of advice would be to stop mailing it to linux-kernel, ... you don't actually need>4GB of memory to test CONFIG_HIGHMEM64G. ... a 512MB machine with plenty of swap, ...
    (Linux-Kernel)
  • Re: Service Pack 3 Update
    ... AV 2006 might give cause trouble with some particular patch because of ... Destroy 1.3 installed and not use TeaTimer while another person has Spybot ... here that are not MVPs that do the same thing - so taking advice from an MVP ...
    (microsoft.public.windowsupdate)
  • Re: a relatively major problem with ext2.
    ... On 3/9/05, Peter Edwards wrote: ... The patch still applies in today's ... # rm -rf foo ...
    (freebsd-current)
  • Re: make -U
    ... > that make couldn't unset variables using make -U. ... > a small patch that adds -U functionality, ... > .ifdef FOO ... and affects all makefiles wishing to ...
    (freebsd-arch)