Calcite’s parent pom is in the root directory of the repo, and it makes sense to keep it there.
So I think Avatica would remain in the avatica directory, avatica/pom.xml would become a parent POM, we’d move avatica-server to become avatica/server and we’d move avatica/src to avatica/core/src. Then we’d add NOTICE, LICENSE, README, site under avatica. And we’d remove <module>avatica</module> <module>avatica-server</module> from the calcite parent pom.xml, and make Avatica’s pom.xml inherit directly from the Apache parent pom. Julian > On Feb 2, 2016, at 11:05 AM, Josh Elser <[email protected]> wrote: > > Any thoughts on how the layout/versioning should work? We could move Avatica > into a top-level directory and have it separated from the "calcite" > repository. So, to build Avatica, you'd have to `cd avatica && mvn <foo>`. > The calcite modules would pull from your local repo or the configured remote > repo(s). This would make cross-cutting changes a bit harder to verify, but > it's probably a necessary evil for the eventual separation. > > I don't think a separate Git repo is required now, but those are pretty cheap > as far as INFRA goes (to my understanding) which is why I had suggested it > originally. > > When I get a moment, I'll make some uber/epic JIRA issue to track the stuff > to do which we can pile on. > > Thanks for your input, Julian and Ted. > > Julian Hyde wrote: >> My feeling is that Avatica ultimately needs to be a TLP, with its own >> governance. Calcite is, in a sense, incubating it until it is ready. My >> concern is that if we "release the pressure” we’ll lose the impetus to make >> it a TLP and get stuck half-way. >> >> That said, Avatica does not have enough activity to be a TLP right now. So >> let’s start the separation, so that Avatica will be perceived as more >> independent. >> >> I think Solr is a good example to follow. It is a sub-project of Lucene but >> is branded separately; for instance, it has its own site: >> http://lucene.apache.org/solr/ but the projects share a dev list. I like the >> idea of Avatica having its own site, say http://calcite.apache.org/avatica. >> >> We will need to create a new site directory (in Jekyll layout), a new >> Avatica parent POM, and a new history.md. However, I am neutral on whether >> the git repos need to be separated at this point. >> >> Julian >> >> >> >>> On Jan 30, 2016, at 8:47 PM, Ted Dunning<[email protected]> wrote: >>> >>> 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 >>>>> >>
