module_author: don't advice putting in an email address

Hi Rusty.

Following up the recent MODULE_MAINTAINER discussion:

http://lkml.org/lkml/2007/4/4/170

that concluded with MODULE_MAINTAINER not being a good idea, here's a small patch that just deletes the advice of including an email address in the MODULE_AUTHOR tag as suggested (and not objected to) at the end of it.

The email address is the problem I was trying to fix; with multiple current and non-current authors and maintainers who might not even be authors the address(es) available from the tag confuse the issue of whom to contact. It's moreover also information that easily outdated.

A bit more than half of the tags in the tree don't include an email address already and I'll submit patches removing more...

Rene.

commit 3b4fa382d5a6a3d9afdcb5a9232d63c47391fb30

Author: Rene Herman <[email protected]>
Date:   Fri May 11 02:24:35 2007 +0200

module_author: don't advice putting in an email address

It's information that's easily outdated and easily mistaken for a driver contact which is a problem especially for modules with multiple current and non-current authors as well as for modules with a maintainer who may not even be a module author.

index 792d483..e6e0f86 100644
@@ -124,7 +124,7 @@ extern struct module __this_module;
  */
 #define MODULE_LICENSE(_license) MODULE_INFO(license, _license)
 
-/* Author, ideally of form NAME <EMAIL>[, NAME <EMAIL>]*[ and NAME <EMAIL>] */
+/* Author, ideally of form NAME[, NAME]*[ and NAME] */
 #define MODULE_AUTHOR(_author) MODULE_INFO(author, _author)
   
 /* What your module does. */

Please don't do this

NACK this change.

Whether someone puts their email address into the entry is their own business. We do not need a style police for module author entries.

At most you might want to put

"If you include an email address then please use an address that
you expect to keep for the long term, and if you change address please remember to update or remove the entry"

And I'll NAK every one which hasn't been signed off by the email address listed OR the address bounces. In which case removing it is good.

Alan

Can't we just subtitle it somehow? Add tags: " (current maintainer)", " (original author, inactive)", " (bug and defect reports)", or whatever you like after the names.

This particular patch just deletes the _advice_ to add an address; if you'd consider it a style issue, you shouldn't be objecting.

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.

The first issue is multiple current and non-current authors only one of which should be contacted for the driver or even _none_ of which should be contacted for the driver. Giving that MODULE_MAINTAINER was concluded to not be a good idea, a maintainer has no place to override an address from MODULE_AUTHOR.

Then the next issue is email addresses getting outdated. I've had my share of bug reports both bounce and not bounce but just not getting any reply and I can assure you it's the kind of frustrating experience that makes you just stop trying. From source and/or MAINTAINERS file they can be deleted but they can't ofcourse from the binary installs on user machines. Even the person listed can't do that, which is issue 3.

You earlier objected to removing the MODULE_AUTHOR tag outright on legal grounds but you yourself are one of the people using only a name and not an address in the tag. In fact, most of the core contributors are, so I assume you don't have that same objection again.

My specific angle is old PC hardware where the drivers have outlived their authors (various ISA junk, legacy CD-ROM, what have you) where I or some other newbie might want to take on maintainership of a driver. I can add myself to MAINTAINERS but not to binary installs, and in fact even on a source level the addresses from the MODULE_AUTHOR tag confuse the issue of who's responsibe for the thing.

This specific problem of mine would be solved by me just deleting the addresses from the specific drivers I'm interested in and just not bothering with anything else. This means the problems outlined above would just live on for everything else though and we happily continue to frustrate bug reporters and maintainers.

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.

Rene.

We should merely advise that the address be reliable and long term

Which is why you want MODULE_MAINTAINER()

Not my fault, not my problem, take it back up with the objectors

The source tree on the users box has the same problem. The author also can't update the kernel rpm packages provided by the distibutor where 99.99% of the users get their data.

I have no problem with people using name only, or name and email. Its not my problem what they use.

You can update the current tree in both cases. You can update neither source nor binary of an existing release. Your argument is bogus.

You can also solve the problem of bugs in drivers by deleting the driver. Both are equivalent neither are very smart.

If you find a bogus maintainer entry email then update/remove it. That way the housekeeping gets done.

Adding new drivers causes future problems, lets stop that too ?

Email addresses in modules are often useful as well - they have utility just like a new driver does. You don't get one without the other.

Alan

Right. Or want_ed_ at least.

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?

Right. So let's stop putting in confusing data in the first place. This is what the patch that you objected to advised (<-- s!).

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.

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.

Yes, that's close to Rusty's version of the original MODULE_MAINTAINER proposal:

http://lkml.org/lkml/2007/4/23/115

If I have the "ignore those other addresses you see listed here please, this is the contact address" method this would provide, I don't believe more annotations would be needed really.

Rene.

This still wouldn't solve the following problems:
- I doubt it will be kept up to date for all > 2800 modules in the kernel
- the 3 year old kernel of your distribution would contain 3 year old maintainership information
- maintainers sometimes disappear

The default for "bug and defect reports" should be for all modules (as well as for non-modular code) from ftp.kernel.org kernels either linux-kernel or the kernel Bugzilla. [1]

For distribution kernels (which are what most users are using), the default for "bug and defect reports" should be the distribution support.

cu
Adrian

[1] contacting the maintainer directly is often better, but there's no sane way to put this information into the kernel binary

       "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

Maintainers sometimes DON'T disappear ....

If users put it in the kernel bugzilla its gets lost because most of the bugzilla isn't set up to route bugs to maintainers. In the unlikely event it arrives there or it gets posted to linux-kernel the only reply is "report it to your distributor"

I'd prefer not. I get reports from people about drivers that got "lost" by vendors, regularly. Nor am I pointing fingers at specific vendors here, last month I sorted out a two year old "lost in Red Hat Bugzilla" kernel bug for example.

Alan

I think I would put something like this:

/* Author, of form NAME[, NAME]*[ and NAME]
* If you have a permanent email address and are prepared for maintaining/supporting the module, you may want to provide the address as well */

The wording isn't the best I suppose.

I.e., the change would mean providing the address is not strictly required and the person should think when adding it, that's all.

Krzysztof Halasa

No disagreement about that.

But things like disappearing maintainers, unmaintained code, and maintainership that is at most informal (e.g. currently the floppy driver) are real-life problems that do occur in several cases.

Bugzilla is actually setup to route bugs of the maintainer, this is currently implemented through the Bugzilla feature "Andrew"...

How many maintainers want to get bug reports against the kernel 2.6.9 shipped with RHEL 4?

cu
Adrian

       "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

The enterprise kernels which tend to be the ones with the long lag also have a userbase with support contracts so tend not to consider l/k as their first support stop anyway.

Not if they use it through CentOS...

And Debian has the same problem with similar old kernels (Debian 3.1 that was the latest stable release until one month ago and
is still supported for one year ships with 2.6.8).

cu
Adrian

       "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