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 <[email protected]> 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] https://bitbucket.org/lalinsky/python-phoenixdb
