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

[Rene Herman <rene.herman@gmail.com>]

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