calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: [DISCUSS] Move Avatica to a sub-project?
Date Tue, 02 Feb 2016 18:52:54 GMT
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”
we’ll 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’s 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: but the projects share a
dev list. I like the idea of Avatica having its own site, say

We will need to create a new site directory (in Jekyll layout), a new Avatica parent POM,
and a new However, I am neutral on whether the git repos need to be separated
at this point. 


> On Jan 30, 2016, at 8:47 PM, Ted Dunning <> wrote:
> 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 *.
> Speaking from experience ages ago with Mahout, having a separate artifact
> that had a different audience than the main project worked just fine.
> On Fri, Jan 29, 2016 at 10:29 PM, Josh Elser <> wrote:
>> 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.
>> 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:
>>> Allow me to play devil’s advocate and to look at some other options.
>>> 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
>>> By the way, I don’t 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’s PMC votes on releases, but DB’s PMC reports to the Apache
>> Board.) I
>>> gather that the Board is apparently no longer very fond of subprojects.
>>> 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’s release schedule.
>>> And let’s 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.
>>> 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).
>>> 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.
>>> Julian
>>>> On Jan 29, 2016, at 12:35 PM, Josh Elser <> wrote:
>>>> Hi all,
>>>> I remember the question about spinning out Avatica was brought up
>> around
>>> the time Calcite graduation to TLP was happening.
>>>> 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:
>>>> * 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)
>>>> 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).
>>>> 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.
>>>> 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?
>>>> - Josh
>>>> [1]

View raw message