Couple of things to add: 1) Related to academic or just a general research perspective - I volunteer to coordinate this area, hopefully together with you Michael, Jesus, and whoever else is interested. Calcite is a great platform to enable this (modularity, expansiveness, etc.) Since you guys are already busy with the PMC roles, I can take a lead, and we can rotate yearly. In terms of output, I propose that we aim for 1-2 strong papers out every year (SIGMOD, VLDB, PODS, etc.), which will accumulate to a nice body of work. We could try to publish some of these in collaboration with downstream projects such as Flink, etc.
2) I would also like to propose a new component to Calcite that could evolve over the next 12-18 months focused on scientific data, starting with support for genomic and related storage managers (TileDB, SciDB, SAMTools, etc.), with specific aim at life and medical sciences. This is, in my opinion, the next big frontier, in addition to the current geospatial focus. 3) I think we'll get the geospatial stuff done by the end of 2018. Best, Edmon On Mon, Nov 6, 2017 at 7:46 PM, Michael Mior <[email protected]> wrote: > Jesús, > > I'm happy to step in as PMC for next year if others are comfortable with > that. As far as the answers to your questions, a few thoughts below. > > 1) I think it's great to see continued growth in new contributors. For such > a widely used project, I've never seen new committers be onboarded so > quickly. It's great to see the scope and diversity of use cases for Calcite > expanding. Although preliminary, things like adding geospatial queries are > opening up a lot of new doors for Calcite and I'm interested to see where > this goes. > > 2) I'd like to see Calcite get more use in academic research. Hopefully the > paper Edmon is currently leading will contribute to that effort. I think > Calcite can make it much easier to prototype query optimizations that > poking around the internals of Postgres or MySQL. (Disclaimer: It's been a > while since I've looked at either of these projects.) > > Also, it would be nice to have the CI process become more stable. Whether > this is some improvements to the current Jenkins infrastructure or the work > Christian is doing on getting things running smoothly on Travis CI. > Furthermore, I don't think the integration tests are run as often as they > should be since it can be a little onerous to set up. I've mentioned before > I think Docker could be a better fit than the current VM solution, > especially if we're able to have separate containers for each service so > they can easily be tested individually. > > Although my answer to question 2 was a bit more verbose, that shouldn't be > interpreted negatively. Although I haven't been involved with Calcite for > very long, I've been impressed with the upward trajectory and I'm sure that > will continue! > > Cheers, > -- > Michael Mior > [email protected] > > 2017-11-06 12:00 GMT-05:00 Jesus Camacho Rodriguez <[email protected]>: > > > It has been a bit over two years since Calcite graduated to a top-level > > Apache project [1]. Back then, it was decided that every year there would > > be a "state of the project" discussion and a new PMC chair/VP would be > > chosen [2]. The time has come :) > > > > The adoption of Calcite has continued growing nicely during the last > year. > > We continued improving the support to query all data, from > semi-structured > > to streaming, including spatial/geographical/geometry data recently. > > Calcite can interact with more systems than ever before and we count > > already more than 12 different adapters into our codebase. In turn, the > > wide adoption of Calcite is helping us to consolidate existing core code > > and extend the tests coverage. > > > > The dissemination of the project continued over the last year, with > > important presence of Calcite in talks at conferences and meetups. In > > addition, some members of the community are trying (for the second time > :) > > ) to produce a paper describing the project, its architecture, and how > > other different systems are using it [3]. There were several discussions > > last year about the difficulty to consume Calcite documentation; we hope > > that this document would serve as an initial formal reference for the > > project. > > > > We also continued with a regular release cadence, which is representative > > of the health of the project as well as useful for the rest of the > projects > > that consume the Calcite bits. Last week, CALCITE-2027 [4] was logged to > > drop support for Java7. I think it is a great opportunity for the project > > to take another step forward, releasing Calcite 2.0 shortly after that, > and > > deprecating some old APIs along the way. > > > > We have a larger, more diverse number of committers and contributors than > > last year, coming both from industry and academia. Their contributions > were > > not limited to code for the project, as we had different members of the > > community playing the release manager role, spending time improving the > > documentation of the project, etc. > > Probably we still need to improve some aspects as a community. For > > instance, recently there were discussions about the participation of the > > community members in one of the important tasks for the project: pull > > requests reviews. This continuous engagement seems to be challenging for > a > > project such as Calcite, as most of us work primarily on other projects > > that "consume" Calcite and we might spend more time involved in those > > projects. While this is difficult to change and I do not have any > specific > > idea to improve it, it is important that we do our best to help and > ensure > > that the project development does not stall. > > > > I am not involved in the Avatica effort, but it has been great to see > > Avatica continue maturing, moving into its own repository and following > > with its own release cadence. Josh, Julian, if you want to add a few > lines > > about the state of Avatica, that would be great. > > > > Since we agreed to rotate the PMC chair every 12 months, I want to use > > this thread to start talking about a replacement too. It has been a > > privilege to be able to serve as Calcite PMC chair during last year, I > wish > > I could have found more time to foster the project further: I truly > believe > > in Calcite vision and its value at the core of the development of open > > source data management systems and applications. > > Which candidates would like to step up? In my opinion, I think Michael > > Mior, if he is willing to accept, would be a great candidate. He has been > > engaged with the Calcite community in different roles, writing code and > > documentation, reviewing PRs, answering questions in the mailing lists, > and > > acting as release manager for 1.14, among others. > > > > Lastly, as Julian asked last year: > > 1) What else are we doing well in the project? > > 2) What are the areas where we need to do better? > > Please take some time to share your thoughts about the state of the > > project. > > > > -Jesús > > > > > > > > [1] http://calcite.apache.org/news/2015/10/22/calcite-graduates/ > > > > [2] http://mail-archives.apache.org/mod_mbox/incubator- > > calcite-dev/201509.mbox/%3CCF8D6F96-706F-4502-B41D- > > 0689E357209D%40apache.org%3E > > > > [3] http://issues.apache.org/jira/browse/CALCITE-2024 > > > > [4] http://issues.apache.org/jira/browse/CALCITE-2027 > > > > > > > > >
