lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46447ABF.3000004@gmail.com>
Date:	Fri, 11 May 2007 16:16:31 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Rusty Russell <rusty@...tcorp.com.au>, bunk@...sta.de,
	randy.dunlap@...cle.com, akpm@...ux-foundation.org,
	rpjday@...dspring.com, marcel@...tmann.org, hch@...radead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] module_author: don't advice putting in an email address

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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ