lkml.org 
[lkml]   [2008]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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


    \
     
     \ /
      Last update: 2008-04-16 14:19    [W:4.443 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site