From dev-return-2528-apmail-calcite-dev-archive=calcite.apache.org@calcite.apache.org Tue Feb 9 23:45:11 2016 Return-Path: X-Original-To: apmail-calcite-dev-archive@www.apache.org Delivered-To: apmail-calcite-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 BD11418F47 for ; Tue, 9 Feb 2016 23:45:11 +0000 (UTC) Received: (qmail 36383 invoked by uid 500); 9 Feb 2016 23:45:11 -0000 Delivered-To: apmail-calcite-dev-archive@calcite.apache.org Received: (qmail 36308 invoked by uid 500); 9 Feb 2016 23:45:11 -0000 Mailing-List: contact dev-help@calcite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@calcite.apache.org Delivered-To: mailing list dev@calcite.apache.org Received: (qmail 36297 invoked by uid 99); 9 Feb 2016 23:45:11 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 09 Feb 2016 23:45:11 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id DD85FC0C0A for ; Tue, 9 Feb 2016 23:45:10 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.28 X-Spam-Level: * X-Spam-Status: No, score=1.28 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id yMek3RpZb0pv for ; Tue, 9 Feb 2016 23:45:09 +0000 (UTC) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id BE4CB2054F for ; Tue, 9 Feb 2016 23:45:09 +0000 (UTC) Received: by mail-pa0-f41.google.com with SMTP id kp3so1753639pab.1 for ; Tue, 09 Feb 2016 15:45:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=kXLKYFAoayPN+RVRypR28PHCaEcCcjzXVJda0jCGFmk=; b=bZ0gQ/akmdkXHmKuIFrBCHGvTPDi6kCc50KKjeRMbA27uGTcJxIsc7e7g7HdNFbBgf iUpEyVXBrSRogKupiolVf0i0L1hfHURzd5n7daT3uO3qeEaq3/6Aj2XcEKXU5+ysloeY ck2G2TRTJUdL1hd2DHz9hBogL5JIZn5kAf69bv4bEUZ/RSnerWiszeLDv4ipWQm0/Dg3 UloAXnViDRLmaagOpXSWSYtugSo7BX4FnAyMpRdIPlaPYiWkYj4moc7SoPobZFP0R7sd dgqTuxxYh8+4zwsPrlA6suIhOOkVHf8nou3LNlx96EB9U0P7lbQOYrT4W465+2jlvAH/ U/7g== X-Gm-Message-State: AG10YOQCzdJ05SgUkTZ6FWjS8hyR1q6yZNiurGbAn30t9X1mzGKCW3tuOn4ucv284vBvXg== X-Received: by 10.66.141.11 with SMTP id rk11mr52133130pab.156.1455061509527; Tue, 09 Feb 2016 15:45:09 -0800 (PST) Received: from [10.22.24.120] ([192.175.27.10]) by smtp.gmail.com with ESMTPSA id ah10sm315572pad.23.2016.02.09.15.45.07 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 09 Feb 2016 15:45:08 -0800 (PST) From: Julian Hyde Content-Type: multipart/alternative; boundary="Apple-Mail=_8398FAD4-5FAB-4B40-B7FF-1D6095F5EEE4" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Apache-hosted CI (was Re: Build error in master branch) Date: Tue, 9 Feb 2016 15:45:07 -0800 References: <56929E7E.2050703@gmail.com> <5BA3E61D-494E-4D65-AED3-E3E4EE575E48@apache.org> <5692D2C8.2000204@gmail.com> <56B4265F.3090107@gmail.com> <56B97B76.2040900@gmail.com> <473ED04D-30C3-4151-85B7-EB51AE44299D@apache.org> <56BA3A35.1010307@gmail.com> <7920FEED-76FF-41F1-94A5-975878375872@apache.org> <56BA3FB7.4000609@gmail.com> <468E048F-7004-4A1A-85AB-16834231BACE@apache.org> To: dev@calcite.apache.org In-Reply-To: X-Mailer: Apple Mail (2.3112) --Apple-Mail=_8398FAD4-5FAB-4B40-B7FF-1D6095F5EEE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As you say, it=E2=80=99s a matter of pragmatics what standards we set = for what goes into master. In my opinion, we should check things which are binary. We can=E2=80=99t = check non-deterministic tests, and we can=E2=80=99t check for = performance. Those will show up over time. We can check for compliance = with automated checks.=20 A *contributor* doesn=E2=80=99t need to run checkstyle every build. But = a *committer* has a special role in Apache as a gatekeeper. I think a = committer should run checkstyle before every commit to master. I don=E2=80= =99t think it is an undue burden to ask a committer to run checkstyle = and javadoc on JDK 1.8. Those things tend to break fairly often, and = it=E2=80=99s a pain to make small fixes and bad practice to force-push. For what it=E2=80=99s worth, I run a clean build, checkstyle, javadoc = and the full regress using https://github.com/vlsi/calcite-test-dataset = , on both JDK 1.7 and JDK = 1.8. I do it in a sandbox that I only use for validating commits, on a = server that runs in my home office. But the full regress doesn=E2=80=99t = find errors very often, and not every committer has enough memory to run = a VM, so I=E2=80=99d make that optional. Julian > On Feb 9, 2016, at 1:30 PM, Vladimir Sitnikov = wrote: >=20 >> especially considering the benefit to all of having the master branch = always at a particular standard. >=20 > That is of no discussion. > You are 100% right here. >=20 > However, that statement is a bit sparse. > What I mean is "a standard" could be to "test javadoc in CI only". > Or even "skip checkstyle for default builds, and check that is CI". > That would allow non-styled code to sneak into repository for a short > time (yet the code is buildable), however it would dramatically reduce > the build times for everyone =3D> thus more time to write better code > and tests. >=20 >> I said that I would not put an =E2=80=9Cundue burden=E2=80=9D on = committers >=20 > I do not ignore that. I'm just trying to understand how far are you > pushing "put more burden" part of the equation. >=20 > I do not like this one as it is a bit broad: > Julian> But I would be inclined to put more burden on the committer >=20 >=20 > Julian> committers need to use whatever tools are that their disposal >=20 > If you mean "committers should use CI" here ^^^, that is perfectly = fine for me. >=20 >=20 > Julian> If the river is not clean it makes everyone=E2=80=99s life = more difficult. >=20 > Frankly speaking, I see no problems if "javadoc build" fails from time = to time. > Does "100% quality" indeed matters that much? > An example how "pre-commit-testing saved the world" would help here to > change my mind. > On the other hand, we have recently used --amend to fix some things > with a great success. > Thus I treat 99.x% as "good enough". >=20 > Just in case: there's a "performance river" (I do remember there's an > issue I need to look into). > I'm not sure if we can and/or need to keep it 100% safe (e.g. "no > commit is allowed to degrade performance for no reason"). >=20 > Well, instead of discussing things in theory, we could just vote to > hear from others. >=20 > Vladimir --Apple-Mail=_8398FAD4-5FAB-4B40-B7FF-1D6095F5EEE4--