<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 20, 2015 at 5:43 AM, David Tardon <span dir="ltr"><<a href="mailto:dtardon@redhat.com" target="_blank">dtardon@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Thu, Nov 19, 2015 at 05:55:01PM -0500, Ashod Nakashian wrote:<br>
> On Thu, Nov 19, 2015 at 5:13 PM, Norbert Thiebaud <<a href="mailto:nthiebaud@gmail.com">nthiebaud@gmail.com</a>><br>
> wrote:<br>
><br>
> > On Thu, Nov 19, 2015 at 10:39 AM, Stephan Bergmann <<a href="mailto:sbergman@redhat.com">sbergman@redhat.com</a>><br>
> > wrote:<br>
> > > By the way, one situation where it is debatable whether all the triggered<br>
> > > builds are useful is if you push a series of changes to gerrit, and<br>
> > Jenkins<br>
> > > does builds for each of the changes in the series. For me at least, in<br>
> > such<br>
> > > a situation it would suffice if Jenkins just only did a build for the<br>
> > > topmost change.<br>
> ><br>
> > Evey commit should build.. bibisect will build each and every one of<br>
> > them eventually<br>
> ><br>
> ><br>
> But isn't that the bibisect build instance, which is unrelated to the<br>
> gerrit builds?<br>
<br>
</span>You did not understand what Norbert was trying to say... Every commit<br>
should _be buildable_. The bibisect builder pick the commits to build at<br>
random, not only the last commit in a series (because there is no such<br>
thing as a commit series in git).<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Maybe I'm confusing things, but in my mind gerrit commits are distinctly different from upstream commits.<br></div><div><br></div><div>I'm assuming bibisect needs to build commits made into upstream, not the gerrit submissions that may or may not make it into upstream.</div><div><br></div><div>Now, when a patch is sent to gerrit, we want to validate whether or not it's buildable. That's good. But if the submitter amends the patch, then it matters not whether the original builds or fails, because it has been amended by a new change and the last one is all that matters.</div><div><br></div><div>This thread is about cancelling builds on the first version of the patch, and building only the latest amended version.</div><div><br></div><div>In other words, it has the same strong guarantees that bibisect would expect, but with less waste on unnecessary builds on outdated patches.</div><div><br></div><div><br></div><div>(I have made note-to-self to be more explicit about the scenario I'm talking about when starting similar discussions. Clearly there are too many closely-related concepts that it's hard to expect everyone has the same frame of mind.)</div></div></div></div>