Re: [RFC] Use cases for 'git statistics'

From: Junio C Hamano <gitster@pobox.com>
Date: May 17, 2008, 00:02 UTC
Message-ID: <7vlk29er1w.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <bd6139dc0805130637saf704e1v2ab67c99da3078c3@mail.gmail.com>

"Sverre Rabbelier" <srabbelier@gmail.com> writes:

Show 12 quoted lines

>>  >>  Details I think need to be provided by maintainer...
>>  >
>>  > Do you mean Junio, or the user of the program?
>>
>>  I mean that all I can provide is speculation.  I'm not, and never was
>>  a maintainer of OSS project, and I don't know what criteria one use
>>  (perhaps unvoiced criteria) to decide whether given patch needs to be
>>  examined more closely, or the cursory browsing should be enough.
>
> I reckon more input from actual maintainers would be needed then.
> Junio: aside from the original list with suggestions you provided,
> could you shine your light as git maintainer on this?

A cursory browsing is enough only when you trust the contributor well. For example, I read patches from Nico to code around the pack generation only once or at most twice before I apply them, and the same thing can be said about git-svn patches from or acked-by Eric. These come mostly from the fact that (1) I know they know the area a lot better than myself do, and more importantly that (2) I know they care deeply about the subsystem they are modifying, and they have good taste.

Project maintainers and old timers become familiar with habits, strengths and weaknesses of known contributors over time, and that is the source of such trust.

A clever enough automated way may be able to identify links between the contributors and the areas they are familiar with, and using such a mechanism people might be able to decide that a patch falls into category (1) above. I am not sure if any automated way could ever decide if a patch falls into category (2) above, though.