![]() | |||||||||||
Messages in this thread |
On 08/14/2007 03:51 AM, Rene Herman 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). > > (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 ;-) Okay, and if a single "maintenance unit" consists of many files, this gets to be too much yes. But they _could_ just grow a header pointing back to the MINTAINERS file/database; /* * MAINTAINERS: 3C359 NETWORK DRIVER */ Thst should keep things minimal enough to keep them updated, no? 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/ | ||||||||||
| Last update: 2007-08-14 04:11 [from the cache] ©2003-2008 | |||||||||||