From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 5E9CA3858D28; Mon, 25 Apr 2022 18:20:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5E9CA3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from reform (deer0x0b.wildebeest.org [172.31.17.141]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 6F0B0302BBED; Mon, 25 Apr 2022 20:20:51 +0200 (CEST) Received: by reform (Postfix, from userid 1000) id EA3BC2E80472; Mon, 25 Apr 2022 20:20:50 +0200 (CEST) Date: Mon, 25 Apr 2022 20:20:50 +0200 From: Mark Wielaard To: Luis Machado Cc: "Frank Ch. Eigler" , Overseers mailing list , binutils@sourceware.org, "gdb@sourceware.org" Subject: Re: Adding binutils to the GNU Toolchain buildbot on sourceware Message-ID: References: <5c1f217a-109c-2973-6c69-abf412133dee@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c1f217a-109c-2973-6c69-abf412133dee@arm.com> X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2022 18:20:56 -0000 Hi Luis, On Mon, Apr 25, 2022 at 01:16:44PM +0100, Luis Machado wrote: > On 4/25/22 11:43, Frank Ch. Eigler wrote: > > > As a general comment, I think we should have a single buildbot entry for the > > > whole of binutils-gdb. > > > > Perhaps! > > > > > Given changes to bfd and opcodes can affect gdb, why not build gdb alongside > > > the other tools? You don't need to run the gdb testsuite, which should make > > > things much more deterministic. > > > > But this is not an argument for building gdb as a part of testing binutils. > > This is an argument for building & testing gdb if binutils changes. > > That is: an additional buildbot job > > An additional buildbot job for gdb/gdbserver would be fine. It's just that a > single build for everything is simpler, in my opinion. > > Is the idea to revive the old buildbot we had for GDB, but for binutils? We could provide some of the builds that the old buildbot did for GDB. But the new builder is not GDB specific and I hope we can learn from the old gdb buildbot. The problem with the old gdb buildbot is that it did too much and had flaky test results. This caused people to not care, think the reports were annoying, broken builds sometimes only got reported after hours or even days. I think we should try to keep builds/checks under 10 minutes, that the checks should be for things that the maintainers think should always be green. So that you get a report about something important breaking within 10 minutes while you still know what you did. Another reason to keep build/check times short is so you can test multiple commits per hour. If there are extra resources then we can also add builders that take longer and/or run testsuites on arches/distros that are known broken. But those would then probably not sent out reports but you would use them to see the current status of some setup that might not be 100% green. And that would probably mean adding more hardware/workers. I assume that knowing that gdb and gdbserver still build OK, without running any tests might be important to the gdb maintainers. And that just a build of gdb and gdbserver will take < 10 minutes on most setups. If so lets just pick one or more of the workers which seem like stable distros/arches that should always build gdb: https://builder.sourceware.org/buildbot/#/workers (don't pick sourceware, which is special, debian-arm64, debian-armhf, debian-i386 or fedora-ppc64 which are too slow) Provide a file list (directories) of files in the binutils-gdb.git repo that should trigger a build. A configure and make line that does a quick build for just gdb/gdbserver which should always build. If the is a make check-something that can be executed quickly, < 5 minutes runtime, and that should always be green please include it. But please exclude anything that takes too long, isn't known all-green or contains flaky tests. And the mailinglist to which to report any failing commits. gdb-patches I assume? Cheers, Mark