"Eric S. Raymond" wrote:
>
> This is a proposal for an attribution metadata system in the Linux kernel
> sources. The goal of the system is to make it easy for people reading
> any given piece of code to identify the responsible maintainer. The motivation
> for this proposal is that the present system, a single top-level MAINTAINERS
> file, doesn't seem to be scaling well.
>
> In this system, most files will contain a "map block". A map block is a
> metadata section embedded in a comment near the beginning of the file.
> Here is an example map block for my kxref.py tool:
>
Good!
> And here's what a map block should look like in general:
>
> %Map:
> T: Description of this unit for map purposes
> P: Person
> M: Mail patches to
> L: Mailing list that is relevant to this area
> W: Web-page with status/info
> C: Controlling configuration symbol
> D: Date this meta-info was last updated
> S: Status, one of the following:
> There may be more than one P: field per map block. There should be exactly one
> M: field.
>
> The D: field may have the special value `None' meaining that this map block
> was translated from old information which has not yet been confirmed with the
> responsible maintainer.
>
> Note that this is the same set of conventions presently used in the
> MAINTAINERS file, with only the T:, D:, and C: fields being new. The
> contents of the C: field, if present, should be the name of the
> CONFIG_ symbol that controls the inclusion of this unit in a kernel.
>
> (Map blocks are terminated by a blank line.)
>
We should use the same filed name of CREDITS e.g. D: for Description.
(maybe you can invert D: description and T: time of last update)
It whould nice also if we include the type of the license (GPL,...).
This for a fast parsing (and maybe also to replace the few lines
of license)
Instead of C: it is more important (IMHO) to include the module name.
Maybe we can include both (modules name are always lower case).
I think that the inclusion of the config option is not important (
considering that it can be easily parsed from the kaos' new makefiles).
giacomo
-
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/
