<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: The committer model in practice</title>
	<atom:link href="http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/feed/" rel="self" type="application/rss+xml" />
	<link>http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/</link>
	<description>freelance software developer</description>
	<pubDate>Tue, 02 Dec 2008 22:10:27 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: warren</title>
		<link>http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/#comment-47</link>
		<dc:creator>warren</dc:creator>
		<pubDate>Tue, 28 Mar 2006 11:51:19 +0000</pubDate>
		<guid isPermaLink="false">http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/#comment-47</guid>
		<description>One of the things we found useful with subversion was to use the post-commit hook that will email you whenever a checkin occurs (well in practice, it emails the developer mailing list) This is a great avenue for impromptu code review when you can look over the code that's been checked in and discuss any issues with the rest of the list.

They're also useful to some extent in monitoring the rest of the team's progress. I'm wary however of letting management folks get these emails, they tend to try and derive naive metrics from them, eg 

"how come X has committed 100 lines of code when Y has only committed 1 line today" even though person Y may have been slaving away all day to reproduce an obscure bug and just checked in a critical fix for it.</description>
		<content:encoded><![CDATA[<p>One of the things we found useful with subversion was to use the post-commit hook that will email you whenever a checkin occurs (well in practice, it emails the developer mailing list) This is a great avenue for impromptu code review when you can look over the code that&#8217;s been checked in and discuss any issues with the rest of the list.</p>
<p>They&#8217;re also useful to some extent in monitoring the rest of the team&#8217;s progress. I&#8217;m wary however of letting management folks get these emails, they tend to try and derive naive metrics from them, eg </p>
<p>&#8220;how come X has committed 100 lines of code when Y has only committed 1 line today&#8221; even though person Y may have been slaving away all day to reproduce an obscure bug and just checked in a critical fix for it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Cohen</title>
		<link>http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/#comment-46</link>
		<dc:creator>Mark Cohen</dc:creator>
		<pubDate>Tue, 28 Mar 2006 10:59:08 +0000</pubDate>
		<guid isPermaLink="false">http://warrenseen.com/blog/2006/03/28/the-committer-model-in-practice/#comment-46</guid>
		<description>I totally agree with your sentiments and observations.  We recently migrated to Subversion and now work with a trunk and a release branch, and by evolution ended up at almost the exact working rules you outlined in the points 1 to 3 above.  We face some problems with skill level, cut-and-paste programming and oddly enough trust similar to what you outline above too.</description>
		<content:encoded><![CDATA[<p>I totally agree with your sentiments and observations.  We recently migrated to Subversion and now work with a trunk and a release branch, and by evolution ended up at almost the exact working rules you outlined in the points 1 to 3 above.  We face some problems with skill level, cut-and-paste programming and oddly enough trust similar to what you outline above too.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
