From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107726 invoked by alias); 3 Nov 2016 06:00:26 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 102505 invoked by uid 89); 3 Nov 2016 06:00:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=farm, our X-HELO: mail-yw0-f172.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iKGlgEmgDGCaO+t1jTa0Y/Or3jbCRTh3ega0ordItZs=; b=E+V1HOAy/zlJu/cdqSOndttg2O/fWbFeDgTHyI1C+GJVGWpEn6zID/mw2Xt69r1t0O QlRmdRDENepI/R9H2AfLRSovrYWsDaFXRCD73kD4N3tTjnND03h/I0FDp+pXwvpoOa+0 1A+01sEP12eA4vUONKqda6U+6Bo4MIrUI2KWlrcBtFHA9umfXh3Dnq2cs2NlqYZ2VuKE 4kpS9w8P2dumS2O3pngx6j9HLYxGdSdBP7FIRR3L9glBc9/GhIoCt6cP1L9ssG+tWUgT Yy+TsJJTxhidlq7zgjuIo7WIFfG53mROfznKINVAOAVMYQqC2sa5+yWM4jjLVY+XzBMz 0X1g== X-Gm-Message-State: ABUngvc+xbpPX4ku1QQHevO8PJ2gya/PZ78sqgYxZqD5AWMqfXCwoTwBp14FUgSw6vhy91NXRU85G0Vgo8ZaNw== X-Received: by 10.129.109.211 with SMTP id i202mr7004382ywc.230.1478152797550; Wed, 02 Nov 2016 22:59:57 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Andrew Pinski Date: Thu, 03 Nov 2016 06:00:00 -0000 Message-ID: Subject: Re: RFC: libc-testresults mailing list To: Joseph Myers Cc: "Carlos O'Donell" , GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-11/txt/msg00097.txt.bz2 On Wed, Nov 2, 2016 at 9:48 AM, Joseph Myers wrote: > On Wed, 2 Nov 2016, Carlos O'Donell wrote: > >> Do we expect that libc-testresults is a superset of those builds we have >> connected to our buildbot CI infrastructure? >> >> Do we expect buildbot test results to go to libc-testresults for archiving? > > If we add a script to mail out results then I think it would be > appropriate to make our buildbot scripts use it (having made sure that > existing buildbot instances have working outgoing mail and documented that > as a requirement for buildbot instances). In that case, yes, it would be > a superset of the buildbot builds (note Andrew was asking about where to > send results from a system not hooked up to our buildbot). Yes; the main reason why I don't have it hooked up to the buildbot is that I need/want the ability to run other things on the same machine like even GCC build and test since build/test of glibc only takes an hour and there is not enough changes going into glibc to dedicate one machine just for glibc testing and one for gdb testing and one of gcc testing. > We can consider questions such as how much goes in test results mails from > such a script, e.g. do we include the full tests.sum (possibly gzipped and > attached) or just results that aren't PASS, what standard information > about the test environment goes in mails, whether to attach (gzipped) .out > files of failing tests if they aren't too many / too big, how mails should > declare that they are the standard output of the script to allow for > automatic parsing. GCC only sends summary of what fails and what I know, that is usually enough to track down failures on some target and when it started to fail and then go back find which exact change broke it. There are many machines available on the "GCC" Compile farm to be able to run tests like this. > > It would of course be expected that if someone's build system starts > flooding the list with multiple mails from identical builds (keeping > rebuilding the same versions continuously, or mail system problems > resulting in duplicate mails) then those mails would be blocked until the > problem is sorted out. We have had that issue once or twice but nothing in the last 2-3 years as far as I know. Thanks, Andrew > > -- > Joseph S. Myers > joseph@codesourcery.com