From dev-return-2490-apmail-calcite-dev-archive=calcite.apache.org@calcite.apache.org Tue Feb 2 18:53:20 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 EA08418039 for ; Tue, 2 Feb 2016 18:53:19 +0000 (UTC) Received: (qmail 94329 invoked by uid 500); 2 Feb 2016 18:53:19 -0000 Delivered-To: apmail-calcite-dev-archive@calcite.apache.org Received: (qmail 94251 invoked by uid 500); 2 Feb 2016 18:53:19 -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 94235 invoked by uid 99); 2 Feb 2016 18:53:19 -0000 Received: from Unknown (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Feb 2016 18:53:19 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 20B0EC0908 for ; Tue, 2 Feb 2016 18:53:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id AJUX0wj4Viop for ; Tue, 2 Feb 2016 18:53:06 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 1F5EF2304B for ; Tue, 2 Feb 2016 18:53:05 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id yy13so103261819pab.3 for ; Tue, 02 Feb 2016 10:53:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=65TEGt1JxTHYIGx6Y680PeXdLLo6PuvrkqfZqczqT7s=; b=F/7dUDYNIofKcmrST7tCxBLcEsbm6HiAXFkFHRNwvp6TZ3Pgvia9KIxZ5c0rXEiOrU +6ihqNGGYAE6iBl0UzbUFzZ6O6uRwkLXg5HNNXdF/+QYkrKNQ/lKNN9iEt35vYaom0r7 MKCIdJsYQqn0k/7iHz/8OW5x3cOIrdp3zOCiUKqFo88d/9t3fFUReAS/Hk/kB8okILmI xbBkxY9hPQNuKa68kJswQq8y8dQsraDtStURdEreg8rsw0b8jEgmkDnylZIVFUTZW7sY 7dQNwC6ZqrKK5bU6yhkPyXaW8sMeA6o109MM+qNVlvXchWiLdHOV7MHN2ul42HeU7x0J 9+qg== X-Gm-Message-State: AG10YOSNseaGCVOHT/Gsorw5kVl5gT3mdkEBFpNCt18pr/y1XFCgAUWDDlvCJszCjI/98Q== X-Received: by 10.66.253.137 with SMTP id aa9mr49126928pad.139.1454439178247; Tue, 02 Feb 2016 10:52:58 -0800 (PST) Received: from [192.168.2.200] (c-50-184-110-23.hsd1.ca.comcast.net. [50.184.110.23]) by smtp.gmail.com with ESMTPSA id v7sm4287297pfa.77.2016.02.02.10.52.56 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 02 Feb 2016 10:52:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: [DISCUSS] Move Avatica to a sub-project? From: Julian Hyde In-Reply-To: Date: Tue, 2 Feb 2016 10:52:54 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <079E5501-4793-44C7-A049-2A055899D1AB@apache.org> References: <56ABCCFF.3010205@gmail.com> <47A8B2DC-3B33-4366-AD94-6B09F03C8B98@apache.org> To: dev@calcite.apache.org X-Mailer: Apple Mail (2.3112) My feeling is that Avatica ultimately needs to be a TLP, with its own = governance. Calcite is, in a sense, incubating it until it is ready. My = concern is that if we "release the pressure=E2=80=9D we=E2=80=99ll lose = the impetus to make it a TLP and get stuck half-way. That said, Avatica does not have enough activity to be a TLP right now. = So let=E2=80=99s start the separation, so that Avatica will be perceived = as more independent. I think Solr is a good example to follow. It is a sub-project of Lucene = but is branded separately; for instance, it has its own site: = http://lucene.apache.org/solr/ but the projects share a dev list. I like = the idea of Avatica having its own site, say = http://calcite.apache.org/avatica. We will need to create a new site directory (in Jekyll layout), a new = Avatica parent POM, and a new history.md. However, I am neutral on = whether the git repos need to be separated at this point.=20 Julian > On Jan 30, 2016, at 8:47 PM, Ted Dunning = wrote: >=20 > I would suggest just having a separate release artifact for a time = before > spinning out a separate TLP. Separate TLP is a pain in the *. >=20 > Speaking from experience ages ago with Mahout, having a separate = artifact > that had a different audience than the main project worked just fine. >=20 >=20 > On Fri, Jan 29, 2016 at 10:29 PM, Josh Elser = wrote: >=20 >> Yeah, sub project is probably not the right terminology in = retrospect. I'm >> not sure what the word for it is: I was suggesting just another = repository >> and everything else stays the same. Glad you knew what I meant to = say. >>=20 >> Maybe the question right now is: what would be gained by having a = separate >> PMC (ignoring community building type questions)? I can envision = Avatica >> eventually being mature enough to be a TLP, but would it help to = start >> splitting things now while trying to grow involvement (and solve the >> community size issues)? Is the middle step worth the effort? >> On Jan 29, 2016 8:27 PM, "Julian Hyde" wrote: >>=20 >>> Allow me to play devil=E2=80=99s advocate and to look at some other = options. >>>=20 >>> What would be the practical difference between a sub-project and = what we >>> have now? >>> * The code split into different repositories >>> * De-coupled release schedule >>> * More distinct web site >>> * But still the same namespace, org.apache.calcite >>>=20 >>> By the way, I don=E2=80=99t think what you are proposing is a = sub-project in the >>> Apache sense. (For example, Apache Derby is a sub-project of Apache = DB. >>> Derby=E2=80=99s PMC votes on releases, but DB=E2=80=99s PMC reports = to the Apache >> Board.) I >>> gather that the Board is apparently no longer very fond of = subprojects. >>>=20 >>> What you are proposing, I think, would be a module of Calcite (or = two - >>> avatica and avatica-server) whose release schedule is decoupled from = the >>> main project=E2=80=99s release schedule. >>>=20 >>> And let=E2=80=99s consider the other alternative: splitting Avatica = out as a >>> top-level project (as ORC recently did from Hive). If Avatica became = a >>> top-level project would naturally have its own repo, release = schedule, >> and >>> could have its own web site and name space, org.apache.avatica. It = would >>> also have its own governance, i.e. a PMC that reports to the Board. >>>=20 >>> It seems to me that Avatica, the software, makes more sense as a >> top-level >>> project. Does it make sense for Avatica, the community? I think so. = You >> are >>> using Avatica for Phoenix independent of Calcite, and others are = doing >>> similar things. The only place we fall short is our number of active >>> members. We need 3 active PMC members to make a release, and we = basically >>> have 2 right now (you and me). >>>=20 >>> If we agree that a TLP is the best option in terms of governance and >>> perception then we could make a push to recruit more Avatica = committers >> and >>> PMC members. >>>=20 >>> Julian >>>=20 >>>=20 >>>=20 >>>> On Jan 29, 2016, at 12:35 PM, Josh Elser = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> I remember the question about spinning out Avatica was brought up >> around >>> the time Calcite graduation to TLP was happening. >>>>=20 >>>> Back then, I think Avatica was too early to really benefit from = this >>> distinction. Lately, I keep finding myself thinking that it might be >> time. >>> Of note, features/improvements that have happened since: >>>>=20 >>>> * Wire compatibility across releases (protobuf provides the >>> building-blocks) >>>> * Much better docs >>>> * Steady increase in custom Avatica clients (people creating their = own >>> client) [1] is the best OSS example I've come across >>>> * Insight into the Avatica server w/o hacking the code: Logging and >>> metrics (still WIP, but hopefully landing soon) >>>>=20 >>>> In other words, we've gotten much better at defining what is = Avatica >> and >>> how to use it, with an emphasis in stability across releases. This = is big >>> because a split from calcite "core" would require a very firm = statement >> of >>> compatibility as Avatica changes would not be directly noticed to = break >>> "core" (as they would now in the same repo). >>>>=20 >>>> What I think makes sense is to spin Avatica into its own = repository, >>> still under the Calcite PMC umbrella. In other words, the Calcite = PMC >> would >>> be responsible for both "Calcite" releases and "Avatica" releases, = and >>> releases of the one don't require a release of the other (although = they >> may >>> continue to coincide). I don't believe their is significant interest = to >>> justify spinning off Avatica into its own project (w/ governance), = thus >> the >>> "sub-project" works well. >>>>=20 >>>> What do others think? Assuming we have release automation down, >>> hopefully the doubled release work would not be a big concern. What = have >> I >>> overlooked? >>>>=20 >>>> - Josh >>>>=20 >>>> [1] https://bitbucket.org/lalinsky/python-phoenixdb >>>=20 >>>=20 >>=20