From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-74304-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 119613 invoked by alias); 2 Nov 2016 13:06:00 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 119532 invoked by uid 89); 2 Nov 2016 13:06:00 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=wish
X-HELO: relay1.mentorg.com
Date: Wed, 02 Nov 2016 13:06:00 -0000
From: Joseph Myers <joseph@codesourcery.com>
To: <libc-alpha@sourceware.org>
Subject: RFC: libc-testresults mailing list
Message-ID: <alpine.DEB.2.20.1611021254190.29297@digraph.polyomino.org.uk>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To
 svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1)
X-SW-Source: 2016-11/txt/msg00057.txt.bz2

Andrew Pinski asked in 
<https://sourceware.org/ml/libc-alpha/2016-07/msg00460.html> about a 
mailing list for sending test results to.

I propose that we create a libc-testresults mailing list for test results 
to be sent to by any kind of automation (not for discussions, if people 
wish to discuss things about the results they should take replies to 
libc-alpha with a meaningful Subject line rather than the subject line of 
the results posting).

This would explicitly include results reporting on e.g. whether glibc 
builds in various configurations, not just results of the glibc testsuite 
itself.  It would also include any systems automatically detecting 
regressions and reporting on those regressions.  It might be useful to 
have something like GCC's contrib/test_summary to collect results and 
information about the configuration and versions of various components 
(and indeed for test runs to automatically record some information such as 
the kernel version on the system, possibly remote, that test programs are 
run on), but this is not required for such a list to be useful.

Comments?

-- 
Joseph S. Myers
joseph@codesourcery.com