Sverre Rabbelier wrote: > On Mon, May 12, 2008 at 1:19 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > * Maintainer: how close should I examine provided patch? > > I'm not sure I understand what you mean with this, perhaps related to > "Name: Finding parts of the content in which a lot of bugs are > introduced and fixed" (e.g., patches to bug prone areas should be > examined more closely). This is, IMHO, the most complex example (at least to do properly). It begins with: does given author have code touching given subsystem (i.e. is it for him/her new contribution wrt. subsystem)? How many commits he/she has affecting given subsystem? How often he/she rewrites code? How many bugs were introduced? Details I think need to be provided by maintainer... > > * Contributor: what happened with my code? > > Do you mean a "track my code" like feature? Showing the movement of a > particular piece of code through the code? (Displaying information > like "moved from foo.c to bar.c in commit 0123456789abcd"?) I was thinking there about "git blame --reverse". > > * Searching where to contribute: what are oldest part of code dealing > > with error messages (find ancient code)? > > In other words, find the lines with the oldest modification time stamp > from 'git blame'? Or find the lines with oldest modification stamp with "die" or "warn", or find which messages are oldest, even if wrapper have changed. P.S. I wonder how hard to be to plug-in such SCM statistic system into something like project management, see "Joel On Software: Evidence based scheduling" (of programming tasks) http://www.joelonsoftware.com/items/2007/10/26.html -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
