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
