+1 > * De-coupled release schedule
There are a couple of times that I want to upgrade the calcite only and not the avatica. On Saturday, January 30, 2016, Julian Hyde <[email protected]> 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 <[email protected] > <javascript:;>> 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 > >
