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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/14/2007 03:19 AM, Arjan van de Ven wrote:

On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote:
On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote:

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.

If the problem is to do with people failing to update the MAINTAINERS file, why would moving the same data into 20 or 30 source files
motivate them to keep it up to date? As far as I can see, that would
just serve to multiply the amount of stale data...

if each .c file has a MODULE_MAINTAINER() tag...
people tend to update .c files a lot better than way off-the-side other
files.

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).

(you could avoid that by placing not a name/address in the maintainer tag but a pointer to somewhere else but at that point this gets to be about solving something else).

Keeping it in the source alone is fine. C files could just embed their MAINTAINERS entry as a header:

/*
 * P: Maintainer
 * M: Mail patches to
 * L: Mailing list that is relevant to this area
 * W: Web-page with status/info
 * T: SCM tree type and location.  Type is one of: git, hg, quilt.
 * S: Status, one of the following:
 */

And probably adding fields:

 * I: Info/Summary (for index files and the like)
 * A: Author
 * G: License

and such. Yes, while we're at it, we can pick better letters or full word tags ;-)

Rene.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux