[ANNOUNCE] xorg-server 1.8.99.904

[Peter Hutterer]

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!