[ANNOUNCE] xorg-server 1.8.99.904
Peter Hutterer
peter.hutterer at who-t.net
Thu Jul 1 21:47:42 PDT 2010
On Thu, Jul 01, 2010 at 05:47:59PM -0300, Fernando Carrijo wrote:
> On Thu, 1 Jul 2010 13:24:02 -0600, Jonathan Corbet <corbet at lwn.net> wrote:
> > On Thu, 01 Jul 2010 16:15:58 -0300
> > Fernando Carrijo <fcarrijo at 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!
More information about the xorg-devel
mailing list