<p>FWIW, might be a good idea trying buildhive a bit, then deciding.  It is working pretty well for jenkins-ci projects, and so much easier than fetch, cherry-pick, test push loop.  </p>
<p>In jclouds, we are setting this up as community members are starting to be more brave (ex refactor things that other PRs can trip), and I&#39;ve needed to put $1 into the jar a few times merging ;)</p>
<p>Seems a pragmatic &#39;wait and see&#39; to try BuildHive a while, but of course, you know better than me about what&#39;s the right choice here.</p>
<p>If you are having any struggle setting up that, let me or Andrew Phillips know, as we had a change into BuilHive recently to deal with our massive build :)</p>
<p>Have fun!<br>
-A</p>
<div class="gmail_quote">On May 28, 2012 1:41 AM, &quot;Manik Surtani&quot; &lt;<a href="mailto:manik@jboss.org">manik@jboss.org</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don&#39;t think everyone has to handle tens of PRs a day.  It&#39;s more like one per person per day, which IMO isn&#39;t unreasonable as long as everyone does their fair share.<br>
<br>
On 27 May 2012, at 14:51, Bela Ban wrote:<br>
<br>
&gt; +1000. I completely agree that if someone has to handle tens of pull<br>
&gt; requests per day, he will *not* seriously look into the request, test it<br>
&gt; etc. So IMO this is a farce, and we might as well go back to trusting<br>
&gt; people, rather than wasting their time...<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On 5/25/12 1:47 PM, Sanne Grinovero wrote:<br>
&gt;&gt; guys, please don&#39;t take me as the one who is again complaining about<br>
&gt;&gt; failing tests; I&#39;m having doubts about the development process and the<br>
&gt;&gt; amount of time this is wasting on all of us.<br>
&gt;&gt;<br>
&gt;&gt; We&#39;re all humans and do mistakes, still it happens so extremely often<br>
&gt;&gt; that this is getting systemic, and discipline could definitely be<br>
&gt;&gt; improved: people regularly send pull requests with failing tests or<br>
&gt;&gt; broken code, and very regularly this is just merged in master.<br>
&gt;&gt;<br>
&gt;&gt; I did it myself a couple of days ago: didn&#39;t notice a failure, all<br>
&gt;&gt; looked good, sent a pull, it was merged with no complaints. Three days<br>
&gt;&gt; later, I resume my work and am appalled to see that it was broken. Now<br>
&gt;&gt; fixing it, but I&#39;ll have to send another pull and wait for it - which<br>
&gt;&gt; feels very pointless, as I&#39;m pretty sure nobody is checking anyway.<br>
&gt;&gt;<br>
&gt;&gt; It looks like as the pull request procedure is having this effect:<br>
&gt;&gt;<br>
&gt;&gt;  # patch writer is not as carefull as he used to be: &quot;someone else<br>
&gt;&gt; will check if it&#39;s fine or not. I have no time to run the tests<br>
&gt;&gt; again..&quot;.<br>
&gt;&gt;<br>
&gt;&gt;  # reviewer has as quick look. &quot;Looks good - in fact I don&#39;t care<br>
&gt;&gt; much, it&#39;s not my code and need to return to my own issues.. worst<br>
&gt;&gt; case someone else will fix it blaming the original author&quot;<br>
&gt;&gt;<br>
&gt;&gt; And then again some incomplete test makes it to master, or a patch<br>
&gt;&gt; which doesn&#39;t even compile is integrated.<br>
&gt;&gt;<br>
&gt;&gt; This pull request process is being a big failure. Shall we stop<br>
&gt;&gt; wasting time on it and just push on master?<br>
&gt;&gt;<br>
&gt;&gt; Which doesn&#39;t mean I&#39;m suggesting &quot;let&#39;s make it worse&quot; | &quot;unleash<br>
&gt;&gt; hell&quot;: we should all take responsibility on any change very seriously.<br>
&gt;&gt;<br>
&gt;&gt; Again, I&#39;m not enjoying the role of &quot;whom who complains on the<br>
&gt;&gt; testsuite again&quot;. Just stating a fact, and trying to propose something<br>
&gt;&gt; to make it work better. We have great individuals on this team, but we<br>
&gt;&gt; need to admit that team work isn&#39;t working and we should deal with it<br>
&gt;&gt; at it&#39;s best; denying it won&#39;t help.<br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt; Sanne<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Bela Ban, JGroups lead (<a href="http://www.jgroups.org" target="_blank">http://www.jgroups.org</a>)<br>
&gt; _______________________________________________<br>
&gt; infinispan-dev mailing list<br>
&gt; <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
--<br>
Manik Surtani<br>
<a href="mailto:manik@jboss.org">manik@jboss.org</a><br>
<a href="http://twitter.com/maniksurtani" target="_blank">twitter.com/maniksurtani</a><br>
<br>
Lead, Infinispan<br>
<a href="http://www.infinispan.org" target="_blank">http://www.infinispan.org</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div>