[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <46C1CFFE.4000001@gmail.com>
Date: Tue, 14 Aug 2007 17:53:34 +0200
From: Rene Herman <rene.herman@...il.com>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
CC: Arjan van de Ven <arjan@...radead.org>,
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 08/14/2007 11:20 AM, 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.
That's just not a complete argument if one accepts that users can be people
without _any_ source tree lying around. There's no reason this user would
believe that any source tree, matching or not, would provide him with beter
information than the information modinfo just spat at him. The only thing
that helps is not have modinfo spit _any_ contact information at him so he
knows to look elsewhere.
And even more importantly ...
PUHLEASE PUHLEASE don't dirty this discussion with binary tags in the first
place! It isn't about MODULE_FOO() tags, it is about tagging /source/ files
to help with putting CCs on patch submissals. People who submit patches sort
of by definition have a current source tree lying around, and do not need to
grab information from any binaries. As such, putting it in a comment inside
the source is all that's relevant here, not anything to do with binaries.
So, let's talk source. If we want to link source file foo.c and the
MAINTAINERS information, we have 3 options:
1. MAINTAINERS --> foo.c
This is what Joe Perches' current 550 piece proposal does. Although I can
hardly wait for version 2 of the patchset, high potential to turn into an
incomplete obsolete mess upon adding, removing and moving files around.
2. foo.c --> MAINTAINERS
Putting a copy of the MAINTAINERS entry in a header in a every single source
file (Joe already nicely provided us with the paths to script something like
that) works but considering that single "maintenance units" might consist of
many source files, people might not bother to keep them all updated and in
sync and really, they shouldn't need to.
Sticking a single backlink to a MAINTAINERS file entry at the top of a
source file might work:
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ ... @@
+/*
+ * MAINTAINERS: IDE/ATAPI CDROM DRIVER
+ */
[ ... ]
3. foo.c <--> some 3rd file <--> MAINTAINERS
Just for completeness and trying to make sure I'm not inventing an or/or but
I don't see any use in this linkage, so it's 1 or 2 it seems.
Note, perhaps after we have a MAINTAINERS source tag, we can discuss whether
or not it could in fact be a MODULE_MAINTAINER() binary tag, but that's then
about something else at that point...
Rene.
-
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/
Powered by blists - more mailing lists