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" <[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]> 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 > >
