Thread (78 messages) 78 messages, 27 authors, 2008-04-17

Re: Reporting bugs and bisection

From: Andrew Morton <akpm@linux-foundation.org>
Date: 2008-04-16 19:22:01
Also in: git, lkml

On Wed, 16 Apr 2008 16:26:34 +0300
Adrian Bunk [off-list ref] wrote:
On Wed, Apr 16, 2008 at 02:15:22PM +0200, Sverre Rabbelier wrote:
quoted
I'm not subscribed to the kernel mailing list, so please include me in
the cc if you don't reply to the git list (which I am subscribed to).

Git is participating in Google Summer of Code this year and I've
proposed to write a 'git statistics' command. This command would allow
the user to gather data about a repository, ranging from "how active
is dev x" to "what did x work on in the last 3 weeks". It's main
feature however, would be an algorithm that ranks commits as being
either 'buggy', 'bugfix' or 'enhancement'. (There are several clues
that can aid in determining this, a commit msg along the lines of
"fixes ..." being the most obvious.)
...
Sounds like an interesting project.
At least with the data we have currently in git it's impossible to 
figure that out automatically.

E.g. if you look at commit f743d04dcfbeda7439b78802d35305781999aa11 
(ide/legacy/q40ide.c: add MODULE_LICENSE), how could you determine 
automatically that it is a bugfix, and the commit that introduced
the bug?

You can always get some data, but if you want to get usable statistics 
you need explicit tags in the commits, not some algorithm that tries 
to guess.
Well yes.  One outcome of the project would be to tell us what changes we'd
need to make to our processes to make such data gathering more effective.

Of course, we may not actually implement such changes.  That would depend
upon how useful the output is to us.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help