<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Nov 19, 2015 at 5:09 PM, Norbert Thiebaud <span dir="ltr"><<a href="mailto:nthiebaud@gmail.com" target="_blank">nthiebaud@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Thu, Nov 19, 2015 at 3:20 AM, Ashod Nakashian <<a href="mailto:ashnakash@gmail.com">ashnakash@gmail.com</a>> wrote:<br>
><br>
> Sorry, I didn't explain well.<br>
><br>
> The patches are related. They are updates based on feedback, partial failure<br>
> or improvement.<br>
><br>
> They aren't bulk pushes (whatever that means). They are updates on a single<br>
> changeset.<br>
><br>
> Why do people send multiple patches per push? That's the right question to<br>
> ask.<br>
><br>
> And the answer is: to improve the previous patch.<br>
<br>
</span>Wrong answer.<br>
The very concept of change-set is that you can work on a patch and<br>
rework it as necessary<br>
there is absolutely no reason to create a second patch on top of a<br>
faulty patch not merged yet.<br>
what should be done is to rework the original patch.<br>
It is the whole point of review-before-merge that gerrit offer.<br>
<span class="">><br>
> Hence my question. If a patch has partially failed, or I got feedback to<br>
> improve it, or (insert reason here), and I want to push an update, why<br>
> should the previous patch still build when it's not necessary?<br>
<br>
</span>There should not be a previous patch at all.. you should amend it not<br>
create another one on top of it<br><span class=""><font color="#888888"><br></font></span></blockquote><div><br></div><div>Norbert, there is clearly a terminology issue in our communication.</div><div><br></div><div>For my purposes of Jenkins builds it matters less how one makes a change and uses git.</div><div><br></div><div>In fact, if you assume that I'm talking about pushing a new commit (not using --amend) then you'd see that my question makes no sense! Because the <span style="color:rgb(0,0,0);font-family:monospace;white-space:pre">Change-Id </span>would be different and Jenkins or anyone cannot link it with a build started by the previous one.<br></div><div><br></div><div>What you describe in terms of 'reworking the original patch' and amending it will result in a new Jenkins build. That's what I'm concerned about.<br></div><div><br></div><div>So your suggested workflow is exactly what I'm describing and that results in multiple builds. Every amend results in a new build. Even though it replaces the previous patch, the previous build still goes on, wasting valuable resources and time.</div><div><br></div><div><b>I'm suggesting that for a given <span style="color:rgb(0,0,0);font-family:monospace;white-space:pre">Change-Id </span>we stop/cancel any ongoing or queued builds for that <span style="color:rgb(0,0,0);font-family:monospace;white-space:pre">Change-Id </span>before starting a new build.</b></div><div><br></div><div><br></div><div>(Also, see David's excellent answer in a separate thread with the same subject. He answered my question, but I think it's important that we are all on the same page, hence my explanation above.)</div><div><br></div><div>Thanks.</div></div></div></div>