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