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.
Signed-off-by: Rene Herman <[email protected]>
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. */
> 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
> > 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.
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.
> > 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
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.
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.
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
> 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
Rene Herman <[email protected]> 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
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
> > 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.
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