linux-kernel - Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch

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: <1187099240.3537.1.camel@laptopd505.fenrus.org>
Date:	Tue, 14 Aug 2007 06:47:20 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Rene Herman <rene.herman@...il.com>,
	Trond Myklebust <trond.myklebust@....uio.no>,
	Mariusz Kozlowski <m.kozlowski@...land.pl>,
	Joe Perches <joe@...ches.com>, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch -
	scripts/get_maintainer.pl


On Tue, 2007-08-14 at 10:20 +0100, Alan Cox wrote:
> > MODULE_MAINTAINER() was discussed a while ago but embedding information into 
> > the binary has the problem you can't ever change deployed systems, meaning 
> > it lags by design. If a maintainer changes, people would still be using the 
> > information from their old binaries, meaning a replaced maintainer might get 
> > contacted for potentially years still (and the new one not).
> 
> And as was pointed out at the time, the people whining about that were
> talking out of the wrong equipment. The supplier of the code can no more
> or less easily change the binary as the matching source tree once its been
> shipped. In fact its probably easier to change the binaries as the
> sources will be left on CD.
> 
> The only non-stale source is git-blame.

the other angle is this: if someone becomes the new maintainer, does he
really want to "maintain" all the really old versions of the code out
there that predate him, or does he only want to go forward? 
He wouldn't know anything about, say, the 2.4.21 version of the driver
anyway... nor would it be reasonable to expect him to.

I can an option where distros just set all the maintainer data to
themselves for long lived enterprise products... since effectively they
are the de-facto maintainers of those codebases.

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

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