From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gandi.kataplop.net (gandi.kataplop.net [46.226.111.114]) by sourceware.org (Postfix) with ESMTPS id CE5363856DD0 for ; Tue, 10 May 2022 12:18:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CE5363856DD0 Received: from [::1] (helo=rl.kataplop.net) by gandi.kataplop.net with esmtp (Exim 4.92) (envelope-from ) id 1noOol-00016W-Ll; Tue, 10 May 2022 14:18:20 +0200 MIME-Version: 1.0 Date: Tue, 10 May 2022 12:18:19 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: RainLoop/1.14.0 From: dkm@kataplop.net Message-ID: Subject: =?utf-8?B?UmU6IOKYoCBCdWlsZGJvdCAoR05VIFRvb2xjaGFpbik6IGc=?= =?utf-8?B?Y2NydXN0IC0gZmFpbGVkICdncmVwIHVuZXhwZWN0ZWQgLi4uJyAoZmE=?= =?utf-8?B?aWx1cmUpIChtYXN0ZXIp?= To: "Mark Wielaard" , gcc-rust@gcc.gnu.org In-Reply-To: <179888aa6094ad8c00dc3bb07f53695f0c5ccceb.camel@klomp.org> References: <179888aa6094ad8c00dc3bb07f53695f0c5ccceb.camel@klomp.org> <20220510110040.F2F743955628@sourceware.org> X-Spam_score: -1.0 X-Spam_bar: - X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-rust@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: gcc-rust mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2022 12:18:24 -0000 May 10, 2022 1:38 PM, "Mark Wielaard" wrote:=0A=0A> On T= ue, 2022-05-10 at 11:00 +0000, builder--- via Gcc-rust wrote:=0A> =0A>> A= new failure has been detected on builder gccrust-debian-i386 while=0A>> = building gccrust.=0A>> =0A>> Full details are available at:=0A>> https://= builder.sourceware.org/buildbot/#builders/27/builds/98=0A> =0A> Just when= we were all green :{=0A> =0A> It isn't clear to me what bors is doing th= ough. It seems to just throw=0A> in commits randomly and then tries to fi= x things up with a merge=0A> commit.=0A> =0A> Is there any way to make bo= rs not do that? It makes the buildbot=0A> unhappy and makes bisecting com= mits really hard.=0A> =0A> Ideally all commits are done on top of the tre= e without these odd merge=0A> commits. So do a simple rebase first, then = commit/push.=0A> =0A=0AI don't think that's possible. I recall reading th= at bors-ng handles it this way and you can't change this behavior. It tes= ts everything waiting in the queue and only split this if tests are KO:= =0A=0Ahttps://github.com/bors-ng/bors-ng=0A=0A"=0AAs commits are reviewed= , bors lumps them into a queue of batches. If everything passes, there wi= ll just be two batches; the one that's running, and the one that's waitin= g to be run (and is accumulating more and more pull requests until it get= s a chance to run).=0A=0ATo run a batch, bors creates a merge commit, mer= ging the main branch with all the pull requests that make up the batch. I= nstead of pushing the merge commit immediately, however, it will instead = push it to the staging branch. They'll look like this:=0A=0AMerge #5 #7 #= 8=0A=0A5: Rename `bifurcate()` to `bifurcateCrab()`=0A7: Call `bifurcate(= )` in the `onland` event handler=0A8: Fix crash in `drive()`=0A=0AIf the = build passes, the main branch gets fast-forwarded to meet the staging bra= nch. Since the main branch contains the exact contents that were just tes= ted, bit-for-bit, it's not broken. (at least, not in any way that the aut= omated tests are able to detect)=0A=0AIf the build fails, bors will follo= w a strategy called "bisecting". Namely, it splits the batch into two bat= ches, and pushes those to the queue. In this example, the first batch wil= l look like this:=0A...=0A"=0A=0A:(=0A=0AMarc