On Thu, Jul 01, 2010 at 05:47:59PM -0300, Fernando Carrijo wrote: > On Thu, 1 Jul 2010 13:24:02 -0600, Jonathan Corbet <cor...@lwn.net> wrote: > > On Thu, 01 Jul 2010 16:15:58 -0300 > > Fernando Carrijo <fcarr...@yahoo.com.br> wrote: > > > > > For sure the information contained in git logs don't measure how > > > high-level the > > > changes are being submitted, but it would be nice to devise some metrics, > > > apart > > > from the usual LOC, which could help us visualize the architectural impact > > > caused by the big players. > > > > I've wanted such a metric for a long time. Lines of code is a terrible > > metric for work done in general, even if you don't want to make a > > distinction between "architectural" and other changes. Changeset > > counts aren't really any better. Among other things, both create poor > > incentives if people actually start to care about the numbers. > > A viable solution would be to weight the hunks of a commit against a database > of > scores for each file, or module, in a project. We could calibrate the database > by assigning higher scores to those files considered cornerstones, in lieu of > the less fundamental ones.
A patch that ends up being a single-liner may take a week to track down. A patch that moves thousands of lines of code may be the result of an unifdef run. Good luck finding some way to measure that ;) Cheers, Peter > Thus, by maintaining a database such as the following: > > File Score > ---- ----- > *.{xml,man,txt} 1 > app/* 3 > doc/* 2 > driver/*.[ch] 3 > xserver/dix/*.[ch] 5 > xserver/hw/*.[ch] 4 xkb/* INT_MAX > we could run a script on a patch like this: > > --- a/dix/dispatch.c > +++ b/dix/dispatch.c > /* FIRST HUNK */ > /* SECOND HUNK */ > > --- a/hw/xfree86/os-support/bus/Pci.c > +++ b/hw/xfree86/os-support/bus/Pci.c > /* THIRD HUNK */ > > and obtain a weighted score of 5 + 5 + 4 = 14 for the whole patch. > > Here be dragons, though. > > > That said, I've still not found a better way of trying to measure > > "who's doing the work," especially in the context of a high-bandwidth > > project like the kernel. If anybody has any ideas, I'm all ears... > > Me too! _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel