Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3E087F082 for ; Wed, 3 Apr 2013 14:53:24 +0000 (UTC) Received: (qmail 38995 invoked by uid 500); 3 Apr 2013 14:53:23 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 38797 invoked by uid 500); 3 Apr 2013 14:53:23 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 38755 invoked by uid 99); 3 Apr 2013 14:53:21 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Apr 2013 14:53:21 +0000 Received: from localhost (HELO mail-ve0-f170.google.com) (127.0.0.1) (smtp-auth username apurtell, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Apr 2013 14:53:21 +0000 Received: by mail-ve0-f170.google.com with SMTP id 15so1767358vea.1 for ; Wed, 03 Apr 2013 07:53:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.151.4 with SMTP id um4mr1500073veb.12.1365000800367; Wed, 03 Apr 2013 07:53:20 -0700 (PDT) Received: by 10.58.128.170 with HTTP; Wed, 3 Apr 2013 07:53:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Apr 2013 07:53:20 -0700 Message-ID: Subject: Re: 0.95 and 0.96 remaining issues From: Andrew Purtell To: "dev@hbase.apache.org" Content-Type: multipart/alternative; boundary=047d7b6dc6e2d32e5104d97603b1 --047d7b6dc6e2d32e5104d97603b1 Content-Type: text/plain; charset=ISO-8859-1 I only suggest a category to toggle on or off for flaky tests. Let's just discuss that first. That seems easy to set up. Then we don't have to commit changes just to run them on Jenkins. The point here seems to be segregate flaky tests and fix them, not leave them in a broken state, nor introduce weird "pass once in a while" new criteria. On Wednesday, April 3, 2013, Ted Yu wrote: > Jean-Marc's idea is interesting. > The tests in this 'flaky' category should succeed, say, once in 5 > consecutive builds. > If particular test fails consistently after a checkin, we should > investigate further. > > > On Wed, Apr 3, 2013 at 4:38 AM, Jean-Marc Spaggiari < > jean-marc@spaggiari.org > > wrote: > > > Or even always have them running in this new category but if one of > > them fails,not tag the build as a fail? That way we can continue to > > keep an eye on them but they are not turning the builds red? > > > > 2013/4/3 Andrew Purtell >: > > > Could we introduce a junit category for flakey tests such that they > don't > > > run unless we activate them with some flag to maven? > > > > > > On Tuesday, April 2, 2013, Stack wrote: > > > > > >> On Tue, Apr 2, 2013 at 6:20 PM, Andrew Purtell > > > > > >> wrote: > > >> > > >> > > - HBASE-7897 Add support for tags to Cell Interface > > >> > > > >> > I think one of us over here could pick this up, let me ask. > > >> > > > >> > > - Unit test fixes > > >> > > > >> > I have some stuff due by the 12th. After that I aim for green trunk > > and > > >> > 0.94 builds on 54.241.6.143, including the Hadoop 2 ones. Will put > on > > my > > >> > hip boots. > > >> > > > >> > > > >> I like Jimmy's suggestion from another thread where we just back out > all > > >> flakey tests and roll them in one at a time into a build that is > usually > > >> blue rather than always red so we can figure which tests and code > > >> destabilize. > > >> > > >> St.Ack > > >> > > > > > > > > > -- > > > Best regards, > > > > > > - Andy > > > > > > Problems worthy of attack prove their worth by hitting back. - Piet > Hein > > > (via Tom White) > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) --047d7b6dc6e2d32e5104d97603b1--