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
    On Wed, Apr 16, 2008 at 04:26:34PM +0300, Adrian Bunk wrote:
    > On Wed, Apr 16, 2008 at 02:15:22PM +0200, Sverre Rabbelier wrote:
    > > 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.)
    > >...
    >
    > 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.

    yes, and doing that would get back to the bureaucracy some people are
    trying to reduce in order to save time to do the real work.

    However, in another project of mine, I've got used to systematically
    indicate the type of change in the subject line. It does not get any
    slower for the author, and it appears in shortlogs. And quite amazingly
    the principle has immediately been adopted by several contributors :

    -----
    Note to contributors: it's very handy when patches comes with a properly
    formated subject. Try to put one of the following words between brackets
    to indicate the importance of the patch followed by a short description:

    [MINOR] minor fix, very low risk of impact
    [MEDIUM] medium risk, may cause unexpected regressions of low importance or
    which may quickly be discovered
    [MAJOR] major risk of hidden regression. This happens when I rearrange large
    parts of code, when I play with timeouts, with variable
    initializations, etc...
    [BUG] fix for a minor or medium-level bug.
    [CRITICAL] medium-term reliability or security is at risk, an upgrade is
    absolutely required.
    [RELEASE] release a new version
    [BUILD] fix build issues. If you could build, no upgrade required.
    [CLEANUP] code cleanup, silence of warnings, etc... theorically no impact
    [TESTS] added regression testing configuration files or scripts
    [DOC] documentation updates, no need to upgrade
    [LICENSE] licensing updates (may impact distro packagers)

    Example: "[DOC] document options forwardfor to logasap"
    -----

    Nothing is mandatory, and I (as the maintainer) can still choose to
    adjust the prefix if I want. But in fact, I only had to to it when
    contributors did not classify their patch themselves. Several other
    tags may be added for LKML, such as "RFC" which is already used,
    etc...

    The advantages of this usage are multiple. Nothing needs to be changed
    in the tools, no header needs to be added, it's still very compatible
    with the mailing-list usages (and helps focusing on specific patches),
    it's absolutely not mandatory and easily tweakable.

    I'd like people in this thread not to forget that what we need is not
    a fantastic tool to work around some developers' weaknesses, but cheap
    (if any) help from the developers to help reviewers. I think that such
    a proposal falls exactly in this category.

    I'm quite ready to use it already (though I do not post often), and
    think that it would still feel natural to many developers since most
    of them are already used to such a format. I think it just requires
    a few starters to get most of us to progressively use such a scheme
    by default.

    Regards,
    Willy



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