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