On Thu, Nov 19, 2015 at 5:09 PM, Norbert Thiebaud <nthieb...@gmail.com> wrote:
> On Thu, Nov 19, 2015 at 3:20 AM, Ashod Nakashian <ashnak...@gmail.com> > wrote: > > > > Sorry, I didn't explain well. > > > > The patches are related. They are updates based on feedback, partial > failure > > or improvement. > > > > They aren't bulk pushes (whatever that means). They are updates on a > single > > changeset. > > > > Why do people send multiple patches per push? That's the right question > to > > ask. > > > > And the answer is: to improve the previous patch. > > Wrong answer. > The very concept of change-set is that you can work on a patch and > rework it as necessary > there is absolutely no reason to create a second patch on top of a > faulty patch not merged yet. > what should be done is to rework the original patch. > It is the whole point of review-before-merge that gerrit offer. > > > > Hence my question. If a patch has partially failed, or I got feedback to > > improve it, or (insert reason here), and I want to push an update, why > > should the previous patch still build when it's not necessary? > > There should not be a previous patch at all.. you should amend it not > create another one on top of it > > Norbert, there is clearly a terminology issue in our communication. For my purposes of Jenkins builds it matters less how one makes a change and uses git. 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 Change-Id would be different and Jenkins or anyone cannot link it with a build started by the previous one. 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. 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. *I'm suggesting that for a given Change-Id we stop/cancel any ongoing or queued builds for that Change-Id before starting a new build.* (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.) Thanks.
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
