<?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: Incubator Repositories Proposal</title>
	<atom:link href="http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/</link>
	<description></description>
	<pubDate>Thu, 20 Nov 2008 07:40:08 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Chris W</title>
		<link>http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/#comment-1556</link>
		<dc:creator>Chris W</dc:creator>
		<pubDate>Mon, 16 Jun 2008 15:45:42 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/#comment-1556</guid>
		<description>Actually Donnie, IIRC, at least for Moz2 development (as necessitated by the massive, included automated, reworkings &#38; mergings) Mozilla uses the Mercurial DVCS.
 I think the point of the central repositories in this policy is the ability to give visibility to all of (merited) large change-sets by devs new to Mozilla (and so who aren't yet authorized under the quality policy for it to be added as a branch). This does mean a new code review &#38; committer approval process, additional to &#38; paralleling that for the submission of patches.

    I can't imagine anyone submitting a test suite that big, so these 11 steps aren't applicable to those. I was glad to read Ray's worthy suggestion that coding tests can be a good beginning towards qualifying as a MozDev with commit privileges. Isn't the corollary then that the review process should be pretty similar? While tests have to be sufficient rather than optimal, there is still the opportunity to learn from another's experience, which should be seized if they can take the time to give feedback. While such feedback (hopefully!) may involve more characters, including "[not] yet", that doesn't mean it outweighs the "thanks for this contribution" sentiment. Our practical learning zone necessarily starts beyond the comfort zone of what we can already do, but we can take small steps if proactive. Of course, great if there's true potential for process streamlining (that justifies the review process to sanction it ;).</description>
		<content:encoded><![CDATA[<p>Actually Donnie, IIRC, at least for Moz2 development (as necessitated by the massive, included automated, reworkings &amp; mergings) Mozilla uses the Mercurial DVCS.<br />
 I think the point of the central repositories in this policy is the ability to give visibility to all of (merited) large change-sets by devs new to Mozilla (and so who aren&#8217;t yet authorized under the quality policy for it to be added as a branch). This does mean a new code review &amp; committer approval process, additional to &amp; paralleling that for the submission of patches.</p>
<p>    I can&#8217;t imagine anyone submitting a test suite that big, so these 11 steps aren&#8217;t applicable to those. I was glad to read Ray&#8217;s worthy suggestion that coding tests can be a good beginning towards qualifying as a MozDev with commit privileges. Isn&#8217;t the corollary then that the review process should be pretty similar? While tests have to be sufficient rather than optimal, there is still the opportunity to learn from another&#8217;s experience, which should be seized if they can take the time to give feedback. While such feedback (hopefully!) may involve more characters, including &#8220;[not] yet&#8221;, that doesn&#8217;t mean it outweighs the &#8220;thanks for this contribution&#8221; sentiment. Our practical learning zone necessarily starts beyond the comfort zone of what we can already do, but we can take small steps if proactive. Of course, great if there&#8217;s true potential for process streamlining (that justifies the review process to sanction it ;).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mitchell Baker</title>
		<link>http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/#comment-1515</link>
		<dc:creator>Mitchell Baker</dc:creator>
		<pubDate>Mon, 09 Jun 2008 05:45:27 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/#comment-1515</guid>
		<description>Donnie:  I'm not sure if you mean the setting up of a repository is trivial.  If so, no argument there.  This is meant to address the policy question of who has access to commit code to it.   It's also easy to set up a private repository for people who want to work together, we don't need policy for that.  

Ray, you're right, this isn't aimed at test code.  You do raise a good point; maybe we should have a way for people to get access to commit test code that doesn't involve the level of review required for commit access to the code we ship as a product.</description>
		<content:encoded><![CDATA[<p>Donnie:  I&#8217;m not sure if you mean the setting up of a repository is trivial.  If so, no argument there.  This is meant to address the policy question of who has access to commit code to it.   It&#8217;s also easy to set up a private repository for people who want to work together, we don&#8217;t need policy for that.  </p>
<p>Ray, you&#8217;re right, this isn&#8217;t aimed at test code.  You do raise a good point; maybe we should have a way for people to get access to commit test code that doesn&#8217;t involve the level of review required for commit access to the code we ship as a product.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ray Kiddy</title>
		<link>http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/#comment-1514</link>
		<dc:creator>Ray Kiddy</dc:creator>
		<pubDate>Mon, 09 Jun 2008 00:07:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/#comment-1514</guid>
		<description>I had hoped this would address the difficulty of submitting patches to test code. Right now, the same policy guides access to the tests and the source, which does not make sense if you want to encourage more people to write tests. This seems more oriented to provided repository access to people doing research projects, which Mozilla always handled.

If MoCo wants to encourage people to check in test code (perhaps as a way to get credibility to later get code access, for example), then 11 steps seems like a lot of steps.</description>
		<content:encoded><![CDATA[<p>I had hoped this would address the difficulty of submitting patches to test code. Right now, the same policy guides access to the tests and the source, which does not make sense if you want to encourage more people to write tests. This seems more oriented to provided repository access to people doing research projects, which Mozilla always handled.</p>
<p>If MoCo wants to encourage people to check in test code (perhaps as a way to get credibility to later get code access, for example), then 11 steps seems like a lot of steps.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Donnie Berkholz</title>
		<link>http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/#comment-1500</link>
		<dc:creator>Donnie Berkholz</dc:creator>
		<pubDate>Fri, 06 Jun 2008 20:30:44 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lizardwrangler.com/2008/06/06/incubator-repositories-proposal/#comment-1500</guid>
		<description>This seems like a whole lot of work to basically duplicate something that's trivial with a DVCS.</description>
		<content:encoded><![CDATA[<p>This seems like a whole lot of work to basically duplicate something that&#8217;s trivial with a DVCS.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
