Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-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 C7D0BD0F5 for ; Mon, 20 May 2013 21:54:39 +0000 (UTC) Received: (qmail 2859 invoked by uid 500); 20 May 2013 21:54:39 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 2814 invoked by uid 500); 20 May 2013 21:54:39 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 2805 invoked by uid 99); 20 May 2013 21:54:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 May 2013 21:54:39 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: error (nike.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 May 2013 21:54:33 +0000 Received: from [10.0.0.19] (91-66-82-235-dynip.superkabel.de [91.66.82.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id 9363814346 for ; Mon, 20 May 2013 23:54:43 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: [2/2] git commit: updated refs/heads/master to 46b141d From: Jan Lehnardt In-Reply-To: Date: Mon, 20 May 2013 23:54:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A2E2218-A369-44C0-8434-A72802692B22@apache.org> References: To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1503) X-Virus-Checked: Checked by ClamAV on apache.org On May 20, 2013, at 22:58 , Dirkjan Ochtman wrote: > On Mon, May 20, 2013 at 4:59 PM, Benoit Chesneau = wrote: >> I was thinking to the INSTALL doc. If e know that these versions are >> broken maybe we should tell it when the 1.3.1 will be released. >>=20 >> Or just fix it, then I wonder why removing it. Maybe we need such >> pressure to fix these errors ;) >=20 > I don't think those versions are strictly broken, since the failures > are intermittent, but it's sure nice if Travis doesn't fail so much. > And I'm not sure the pressure is high enough to get people to look at > intermittent issues? Also, Travis doesn't really seem to give a whole > lot of context to make it easy to see why tests fail (but that might > just be me). Nope, +1, that=92s my reasoning as well. Ideally, once we have proper CI set up, we will be testing against all possible dependency combinations that we want to support, but can=92t = have that on Travis anyway, so we may as well slim this down a little and keep it around as a public sanity check. Jan --