[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Parseable tracking of code contributions.

From: <kfogel_at_collab.net>
Date: 2005-07-14 18:48:18 CEST

Ben Collins-Sussman <sussman@collab.net> writes:
> I have to admit, I don't understand the difference between "Analysis"
> and "Review". Seems like hair-splitting. Nor do I understand the
> need for "Approved by", except in situations where we're tracking
> votes (like backporting patches).
> Why not just
> Patch by:
> Reviewed by:
> I mean, aren't analysis and review the same thing? And if the change
> was committed to the repository, then isn't it safe to assume that it
> was approved not only by the reviewers, but most likely the person
> doing the commit?

It's not hair-splitting; they're totally different things. We may
decide not to track both, or to overload the same term, but the things
themselves are different:

"Review" is when someone reviews your patch.

"Analysis" is when someone analyses the *problem*, thus helping you to
*produce* a patch.

Someone may contribute analysis without ever reviewing the resulting
patch. Someone may review a patch without having contributed at all
to the analysis leading to that patch. In fact, these are the norms;
while there are commits where the same person contributes both review
and analysis, they don't seem to be the majority.

Search the logs for "analysis" to see many instances of people
contributing analysis without review, for example.

The reason I'm interested in tracking analyses in a parseable way is
that it helps identify the sort of behavior we look for new

Now that all this is clear, do you still feel the same way about it?


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 14 19:38:00 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.