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

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

[Rene Herman]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

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.


[-- Attachment #2: module_author.diff --]
[-- Type: text/plain, Size: 1029 bytes --]

commit 3b4fa382d5a6a3d9afdcb5a9232d63c47391fb30
Author: Rene Herman <rene.herman@gmail.com>
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.
    
    Signed-off-by: Rene Herman <rene.herman@gmail.com>

diff --git a/include/linux/module.h b/include/linux/module.h
index 792d483..e6e0f86 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -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. */

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

[Alan Cox]

> 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...

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"

> 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...

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

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

[John Anthony Kazos Jr.]

> > 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...
> 
> 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"
> 
> > 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...
> 
> 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.

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.

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

[Rene Herman]

On 05/11/2007 12:46 PM, Alan Cox wrote:

>> 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...
> 
> 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.

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.

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

[Alan Cox]

> > Whether someone puts their email address into the entry is their own
> > business. We do not need a style police for module author entries.
> 
> This particular patch just deletes the _advice_ to add an address; if you'd 
> consider it a style issue, you shouldn't be objecting.

We should merely advise that the address be reliable and long term
> 
> 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()

> 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

> 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.

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.

> 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.

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

> 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.

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

> 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.

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.

> 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 ?

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

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

[Rene Herman]

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.

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

[Rene Herman]

On 05/11/2007 01:42 PM, John Anthony Kazos Jr. wrote:

> 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.

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.

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

[Adrian Bunk]

On Fri, May 11, 2007 at 07:42:38AM -0400, John Anthony Kazos Jr. wrote:
> > > 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...
> > 
> > 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"
> > 
> > > 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...
> > 
> > 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.
> 
> 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 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

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

[Alan Cox]

> 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

Maintainers sometimes DON'T 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]

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"

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

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

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

[Krzysztof Halasa]

Rene Herman <rene.herman@gmail.com> writes:

> /* 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] */

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

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

[Adrian Bunk]

On Fri, May 11, 2007 at 10:35:00PM +0100, Alan Cox wrote:
> > 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
> 
> Maintainers sometimes DON'T disappear ....

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.

> > 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]
> 
> 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

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

> it arrives there or it gets posted to linux-kernel the only reply is
> "report it to your distributor"
> 
> > For distribution kernels (which are what most users are using), the
> > default for "bug and defect reports" should be the distribution support.
> 
> 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.

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

> Alan

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

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

[Alan Cox]

> > 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.
> 
> How many maintainers want to get bug reports against the kernel 2.6.9 
> shipped with RHEL 4?

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.

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

[Adrian Bunk]

On Sat, May 12, 2007 at 01:15:30PM +0100, Alan Cox wrote:
> > > 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.
> > 
> > How many maintainers want to get bug reports against the kernel 2.6.9 
> > shipped with RHEL 4?
> 
> 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