Re: Reporting bugs and bisection

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.) In the light of this recent discussion, especially the part on "keeping count of the number of errors introduced by author and reviewer?", I thought it might for the kernel mailing list to be aware of this. Also mentioned in this thread was that reviewers don't get enough credits. As long as patches are signed with, say, 'reviewed-by:', 'acked-by:' or 'signed-off-by:' the command I suggest to implement would be able to give more accurate statistics on who "works on the kernel". This way reviewers get the credit they deserve. The knife cuts on both sides of course, if someone reviews a patch that is later determined to introduce a bug, they can be recorded to have acked a buggy commit. This is especially interesting in determining who are the good reviewers, but also in determining who are the good contributors. A distinction could be made between parts of the source, say, a maintainer might excel in patches related to driver foo, but when they submit a patch for driver bar it usually contains bugs . Armed with these statistics reviewers might decide to be more careful before acking a patch from that maintainer if it's on driver bar, but when that same maintainer sends in a patch from driver bar it is probably ok and needs less attention. My application, and a more extended description, can be found here: http://alturin.googlepages.com/gsoc2008

I'm interested to know if the community is indeed as interested in my proposal as I hope and if I oversaw any obvious features that would make it an even better command.

Cheers,

Sverre Rabbelier