From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10634 invoked by alias); 29 Jul 2016 11:53:37 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 10625 invoked by uid 89); 29 Jul 2016 11:53:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.0 required=5.0 tests=BAYES_40,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*r:0400, indication, junior, squash X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 29 Jul 2016 11:53:26 +0000 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id C8.B9.02568.2E34B975; Fri, 29 Jul 2016 13:54:10 +0200 (CEST) Received: from elxa4wqvvz1 (147.117.188.8) by smtps-am.internal.ericsson.com (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 29 Jul 2016 07:49:10 -0400 References: <8760rpef2m.fsf@redhat.com> User-agent: mu4e 0.9.17; emacs 24.4.1 From: Antoine Tremblay To: Sergio Durigan Junior CC: GDB Patches Subject: Re: [GDB BuildBot] New "Try Server" In-Reply-To: <8760rpef2m.fsf@redhat.com> Date: Fri, 29 Jul 2016 11:53:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00372.txt.bz2 Sergio Durigan Junior writes: > Last, but not least, your try build will generate its own testsuite > logs, which will be recorded in that builder's git repository, available > at: > > Humm won't that "pollute" the builder results ? I mean, if the builder is testing commit 1 2 3 and that those are commits that were done on master but there's a try patch coming in between named say 7 and it has higher priority. You will then have 1 2 7 3 being tested. Then when we want to check the results of 1 2 3 won't it be confusing to see 7 there ? Will there be an indication that it's a try patch ? Also since the regressions are calculated from one build to the next won't that possibly be a problem if let's say build 7 introduces a FAIL, then build 3 has the same FAIL, but build 2 had a PASS ? We would then miss a regression on a master commit. Should we have separate try builders to avoid that? I'm also curious about what happens if you send it a series of patches, will it squash them ? In any case thanks for working on this :) I'm sure it will be quite useful.