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]
Date:	Wed, 4 Apr 2007 21:12:59 +0200
From:	Adrian Bunk <bunk@...sta.de>
To:	Rene Herman <rene.herman@...il.com>
Cc:	Takashi Iwai <tiwai@...e.de>, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Marcel Holtmann <marcel@...tmann.org>,
	Christoph Hellwig <hch@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: MODULE_MAINTAINER

On Wed, Apr 04, 2007 at 08:01:31PM +0200, Rene Herman wrote:
> On 04/04/2007 07:48 PM, Adrian Bunk wrote:
> 
> >On Wed, Apr 04, 2007 at 07:00:18PM +0200, Takashi Iwai wrote:
> 
> >>But in general, it would be nice to have an easy way to find a
> >>maintainer (not author) from a module binary, and I agree
> >>MODULE_MAINTAINER can work well for such a purpose.  It's no mandatory
> >>field, but could be some help.
> >
> >Yes, it would be nice.
> >
> >But would this information always be kept up-to-date for the whole tree?
> >I don't see this happen.
> 
> I believe it would largely stay up to date yes. The tag wouldn't be 
> mandatory and adding oneself as a MODULE_MAINTAINER would specifically 
> be saying "yes, I want to look after this thing". If someone then no 
> longer wants to, getting rid of the tag is a matter of deleting one 
> line. I wouldn't be worse than MAINTAINERS, and being inline, I expect 
> it to be better...

- often module maintainers disappear suddenly or slowly without any
  clear statement that maintainership ended
- most drivers are not maintained on a per-driver but on a per-subsystem
  basis

Consider that we don't even manage to keep MAINTAINERS correct, and 
consider that we are talking about more than 2800 modules.

Realistically, users should report problems with vendor kernels to the 
vendor and problems with ftp.kernel.org kernels to either linux-kernel 
or the kernel Bugzilla, and forwarding issues to the responsible people 
(if any) should be done there [1].

> Rene.

cu
Adrian

[1] Andrew is doing this

-- 

       "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

-
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