[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080416120247.c665859c.akpm@linux-foundation.org>
Date: Wed, 16 Apr 2008 12:02:47 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Adrian Bunk <bunk@...nel.org>
Cc: sverre@...belier.nl, git@...r.kernel.org,
linux-kernel@...r.kernel.org, jmorris@...ei.org,
viro@...iv.linux.org.uk, w@....eu, david@...g.hm,
sclark46@...thlink.net, johnpol@....mipt.ru, rjw@...k.pl,
tilman@...p.cc, Valdis.Kletnieks@...edu, lkml@....ca,
davem@...emloft.net, jesper.juhl@...il.com,
yoshfuji@...ux-ipv6.org, jeff@...zik.org, netdev@...r.kernel.org,
davidn@...idnewall.com
Subject: Re: Reporting bugs and bisection
On Wed, 16 Apr 2008 16:26:34 +0300
Adrian Bunk <bunk@...nel.org> 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.)
> >...
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists