On Sat, Jun 30, 2007 at 09:32:05AM -0700, Andrew Morton wrote: >[..] > > > Given a set of historical modifiers of a file, > > would you take the most common commiter(s), or the most common > > _recent_ commiter(s), or what? It's a bit fuzzy. > > All the above? Multiply frequency by recency, pick the top five? > > Doesn't matter much: the cost of picking too many is high. > > I shudder at the thought of manually maintaining anything like this.
Why? It shouldn't take much more effort than the effort currently being taken to maintain the MAINTAINERS file as it is. This field can even be considered optional - i.e. let the maintainers themselves who usually send patches to MAINTAINERS just to update their mailing address add this field _only if they want to_. Heck, this way it would even help us to see which maintainers are more attentive :) > > Moreover, it is slow in comparison and assumes the availability of > > local .git db, which wouldn't be the case for some porition of patch > > submitters. > > a) precalculate the tables once per week > > b) the whole thing wouldn't succeed if it requires software at > patch-submitter's site. It'd need to run at vger. > And: c) The script will need to query vger for each file in the patch via some protocol.. Do you think it's worth the effort? -- Dan Aloni XIV LTD, http://www.xivstorage.com da-x (at) monatomic.org, dan (at) xiv.co.il - 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/