> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
