From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 04D033870891 for ; Thu, 14 Jan 2021 13:19:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 04D033870891 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Paul.Zimmermann@inria.fr X-IronPort-AV: E=Sophos;i="5.79,347,1602540000"; d="scan'208";a="370002848" Received: from tomate.loria.fr (HELO tomate) ([152.81.10.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2021 14:19:10 +0100 Date: Thu, 14 Jan 2021 14:19:10 +0100 Message-Id: From: Paul Zimmermann To: Carlos O'Donell Cc: tuliom@ascii.art.br, adhemerval.zanella@linaro.org, libc-alpha@sourceware.org In-Reply-To: <8338bca0-9b10-6ad7-3b3a-aa44c0c14970@redhat.com> (message from Carlos O'Donell on Thu, 14 Jan 2021 07:59:37 -0500) Subject: Re: New math test failures on Fedora/33 References: <4b0af99b-8353-7201-ec79-aae1b8eada70@linaro.org> <44e1b250-8946-4d8a-614e-f2e20c3f1f33@linaro.org> <6eead3d5-56c7-1332-a978-8663bd296522@linaro.org> <87eeiq0xz9.fsf@linux.ibm.com> <8338bca0-9b10-6ad7-3b3a-aa44c0c14970@redhat.com> X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_NUMSUBJECT, LIKELY_SPAM_BODY, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2021 13:19:14 -0000 Dear Carlos, > DJ and I have been discussing this as a project for 2021. > > More importantly I think we need to shift this to CI/CD and integrate it > into patchwork. I want to see fails reported per-patch. Then glue the > CI/CD into that using new infrastructure (runners + builbot try bot). > > I continue to feel that we need confidence to integrate new patches and > that confidence doesn't come from build bots, but comes from CI/CD during > review for reviewers assistance. I still want to get to 100 patches reviewed > in a day and I need automated help to get there. > > I want to see a process where we get email back immediately into a patch > thread (consider each patch thread like a PR) and it includes a try bot > result. > > Then (and this idea I attribute to Konrad Kleine from the Red Hat Platform > Tools team) I want the reviewer to interact with the try bot by email with > special commands e.g. @build build-many-glibcs, to kick off a single bmg > run with the patch in the thread that is tied to the patchwork object. > This way the reviewer is in charge of exactly which background additional > task is required to be carried out by CI/CD and report back the results > in the thread for public review. this looks quite promising! > > I am no sure if we are allowed to run buildbots on gcc compiler farm > > infrastructure. > > AFAIK we are not. I asked people in charge of the gcc compiler farm and they told me that glibc buildbots are welcome on the farm (Tulio and Adhemerval were in cc). Paul