From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 422A2396E852 for ; Wed, 14 Oct 2020 15:50:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 422A2396E852 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ro@cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id D3FFE112CC; Wed, 14 Oct 2020 17:50:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUJOoa5Vv_YH; Wed, 14 Oct 2020 17:50:46 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddb2f4.dip0.t-ipconnect.de [79.221.178.244]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id D105DFFA6; Wed, 14 Oct 2020 17:50:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1602690646; bh=FxIhDSt2TEI3rKK6w4qNd/LkrDLMfb2pKv4S6+nMfUY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=e+Yq3bl4u7JBuk3kowJGoR1fKDsyka+Z62ROCAoLbUoKGJdCPxSHGYIpDexZIbu94 W/DssEEy7w/T+F/dxqKAB53tHF8CJa2PGdxgGweMK9wWzfEGxeW53onTDcq4+bG0ZJ qJdpAwRfvaVGZcmRtFWDPJIxt07aqAJioaJdbXizTFUUeW2fUUyBTZzZPLrvt4ulWK 3PbThetEPYVP415utN8EaLs0eQBYjfqgRG7cpoL06aumdDUNxX9hZnqbKcB4wdNOmJ b+kl2k8be23tMre5OoC6Q6vuXDLHKyglL7i/UbRIU3zF007sQYo5j6nY630rOavglF Bma9teFzLG70w== From: Rainer Orth To: Simon Marchi Cc: Luis Machado , "gdb\@sourceware.org" Subject: Re: Regressions getting more common References: Date: Wed, 14 Oct 2020 17:50:44 +0200 In-Reply-To: (Simon Marchi's message of "Wed, 14 Oct 2020 10:41:45 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-3789.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 14 Oct 2020 15:50:50 -0000 Hi Simon, > I think it would be good to reboot the buildbot, but start by focusing > on what delivers the best "bang for the buck". I remember workers > lagging a lot behind, meaning we would get notifications of breakage > quite a lot after a commit was pushed. I think it would be good to not > make the workers build all commits on master. Either do one build a > day, or have them constantly build the current master (as a background / > low priority task). If there's a regression, then there's a window of > commits that might be responsible for it. But in any case, I would see > having a stable post-commit CI as the first step. maybe we can learn a thing or two from the LLVM buildbots https://llvm.org/docs/HowToAddABuilder.html with the config at https://github.com/llvm/llvm-zorg For one, they do group several commits into one build if the bots lag too far behind (which is a strict necessity given the enormous size of LLVM, even if many bots have a smaller scope like only testing clang, compiler-rt/the sanitizers, ...). Another possibility is not to run full builds every time but only under special circumstances (haven't fully understood which those are, but I'm operating the Solaris buildbots in that mode to avoid overwhelming them), defaulting to incremental builds. Given that GDB build times are reasonably short (a matter of minutes usually), I'm unsure if this is necessary, though. > Then, we can look at having try jobs work again. I never really liked > submitting try jobs through the buildbot command line tool, I always > found there was to little feedback (did my upload work? what jobs did I > initiate?). I would receive test results by email and would have a ahrd > time figuring out which result was for which patch. I have to admit I haven't ever used the try jobs myself. However, AFAIK they still do work with the current buildmaster. Only the jobs triggered by commits seem to have stopped. That said, they are certainly useful, especially to allow people to test their patches on uncommon targets. I know for a fact that several GDB developers used my Solaris bots that way. While the GCC compile farm could be used as well, this means much more effort for the developers. However, as a maintainer of two of those bots, I'd be little pleased to have to maintain and watch over two different packages for this purpose: the charm of the current buildbot setup is that is serves both (as does, e.g. the trybot component of the golang farm). > One idea would be to re-use the now abandonned Gerrit instance for this. > Those who have use Gerrit will probably agree that it integrates quite > well with CI. After pushing your patch for review, you can ask the CI > to test a given patch (often by setting a label on it). The CI posts a > comment on the patch with a link to the build, so you can follow it if > you want. Once it has ran, the CI posts comments on the patch to say > that version N of the patch has this result, again with a link to the > build. > > I would be happy to help take over maintenance of the buildbot master > from Sergio, but I wouldn't want to be alone in this. It would be really great if the GDB bots could get started again. However, I'm unable to help: way too much on my plate already. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University