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

Rene Herman
2007-08-13T18:37:07Z

On 08/13/2007 07:42 PM, Arjan van de Ven wrote:

> On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
>> Hello,
>>
>> I don't recall discusion about this so here are my 3 cents:
>>
>> I like the idea.
>
> I don't actually. It shows a central MAINTAINERS file is the wrong
> approach; just that 500+ patches to the same file were needed shows
> that.

Quite.

> The maintainer info should be in the source file itself! That's the only
> reasonable way to keep it updated; now I'm all for having it machine
> parsable so that tools can use it, but it still really should be in the
> code itself, not in some central file that will always just go out of
> data, and will be a huge source of needless patch conflicts.

This is quite like the OO-INDEX discussion now going, where I saw it argued
that the one-line summaries could go at the top of the actual Documentation
files themselves, where they could be mechanically extracted to _build_ the
index files. Keeping things in sync is the important reason there as well.

While the notion behing these patches appears to be good, the tree sees many
changes through addition, removal and movement of files which affects this.
Is Linus's copy of git going to check if an added file doesn't overlap with
an existing wildcard in the MAINTAINERS file and delele or adjust wildcards
upon removal or movement?

I personally think it wouldn't be such as bad idea to introduce a standard
Linux source file header, with (when present) information such as the
summary for index files, maintainer information, and other information now
present in MAINTAINERS. With it being in the sourcefile themslves, it will
stand a much better chance of staying up to date.

Rene.