Re: [PATCH] [1/2many] - FInd the maintainer(s) for a patch -scripts/get_maintainer.pl

[Arjan van de Ven]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/