Hi Stamatis, Thanks for your great work! I am feeling lucky to have you as our chair in 2020!
Concerning the problem of PR reviewing, one method that comes to my mind is to divide Calcite into a few sub-areas, and assign some owners to each sub-area (based on code contribution, etc.). So once a PR is submitted, the author could request review from the corresponding sub-area owners (github could help with this as well), and the owner can decide to review/triage/close the PR. In this way, the responsibility for reviewers could be made clearer. +1 for voting Haisheng as our next chair. I believe he will be a great chair! Best, Liya Fan On Mon, Nov 9, 2020 at 7:30 AM Francis Chuang <[email protected]> wrote: > Hey Stamatis, > > Thanks for putting this together for 2020. Thank you for being our chair > for 2020 and the excellent work you have done in this capacity. > > I agree that reviewing pull requests is still an issue with the project > and while we have made a lot of progress it this area, it's still > something we need to work on and improve. > > I am also glad that you raised the point regarding Avatica. I've been > meaning to write a message to the list to see if there are things we can > do to help Avatica as I've had some concerns about it for a while: > - Avatica seems to be quite mature and the code quite stable. > - There are 14 open PRs at the moment, so not a huge amount, but they > don't seem to be reviewed although Danny and Josh has picked a few out > to review during the year. > - To an outside observer, it looks like the project is not under active > development, other than the occasional commit every once in a while. > - I believe Avatica is still a critical component for other projects, > Phoenix is one that comes to mind, however, PRs not being reviewed can > discourage potential contributors. > - As there are only 14 open PRs at the moment, I think it would be > really great if the community could spare some cycles and merge, review > and close out those PRs. Quite a few of them have been hanging around > for a few years and if they are no longer relevant, I think they should > be closed. > - I'd definitely love to see more contributors to Avatica in terms of > reviewing PRs and merging. Does the community have any suggestions on > how we can do this better? > > +1 for proposing Haisheng Yuan as our next chair, I think he will be an > excellent choice! > > Francis > > On 5/11/2020 9:26 am, Stamatis Zampetakis wrote: > > Hi Calcite community members, > > > > A bit more than five years ago (October 22, 2015) Calcite graduated to a > > top-level Apache project[1]. At that time, the community decided to have > an > > annual “state of the project” discussion and to vote for a new PMC > > chair/VP[2]. So, I’m kicking off both of those discussions. > > > > I think it was an excellent year so far in many aspects. > > > > We were lucky to have many high quality contributions including: notable > > improvements in the Volcano planner (for speed, plan quality, > > extensibility) bringing it a bit closer to Cascades and Columbia [6, 7, > 8, > > 9]; easier and more extensible parameterization of rules [3]; new > dialects > > such as ClickHouse [4], and Presto [5]; support for SQL hints [10]; new > > adapters for querying Redis [11] and InnoDB [12] through Calcite; various > > enhancements in streaming SQL. The previous list is by no means > exhaustive. > > > > Apart from the new features, certainly worth mentioning is the > > modernization of the build and test infrastructure (for both Calcite and > > Avatica), with the migration from maven to gradle, JUnit4 to JUnit5, and > > the introduction of GitHub actions as part of the CI. > > > > In terms of CI, I am happy to see a few more integration tests (IT) > running > > on a regular basis on GitHub. Eventually, it will be nice to have even > more > > IT tests to help us catch regressions early on and improve the quality of > > our releases. > > > > We wouldn’t have so many great contributions, if we didn’t also have > > prolific contributors. > > Our community has grown with Danny, Haisheng, Ruben, joining the PMC, > > Forward, Xing, Vineet, Yanlin, Feng, Rui, joining as committers, and many > > more people chiming in discussions, reviews, and submitting pull > requests, > > who are not yet committers but I’m sure some of whom will become in the > > near future. > > > > We have had five Calcite releases (1.22.0 to 1.26.0), one Avatica release > > (1.17.0), and one Avatica Go (5.0.0) so far in 2020, and I think that is > a > > great tempo that we should strive to maintain in the years to come. One > > thing to improve is the poor implication of other people than Francis on > > the Avatica side; the rest of us, putting myself first, should try to be > > more involved by reviewing PRs, preparing releases, voting etc. > > > > It was nice to see our community members giving talks to conferences such > > as ApacheCon, and Flink Forward presenting Calcite and/or its > application. > > Some of us have also done presentations in universities in order to > > introduce Calcite to the next generation of computer engineers. One or > two > > conferences per year is a good number but it would be even better if we > > could increase this frequency. There are still many people, especially > > younger engineers, who are not aware of Calcite (at least this is the > > impression that I get by speaking with people in Europe) and we should be > > more active on the project’s dissemination. > > > > Calcite is a very versatile library/framework that can be used in many > > contexts. On one side, it is used in many production systems and utility > > apps with the most recent adopters being Hazelcast, Ignite, SuperSQL > > (Tencent), and NeuroBlade. On the other side, its adoption in research > > projects and teaching could be boosted. Every university has multiple > > projects and courses around databases and data integration where Calcite > > could be a good fit. > > > > Over the past few years we always had problems with reviewing pull > requests > > and I don’t think we made much progress on this aspect. In our last > > discussion around this topic, Julian suggested introducing some metrics > and > > giving credit to those people that are doing the most in this area, and > we > > all agreed to do so. Any ideas on improving this situation are highly > > appreciated. > > > > Calcite is a vivid community and we are lucky to participate in many > > fruitful discussions. Of course, in every community there is some > friction > > from time to time and the same goes for Calcite. It is a bit unrealistic > to > > claim that we can eliminate it entirely but we can try to reduce it, by > > being more attentive and patient. > > > > Being PMC chair was a big learning experience for me and I am very > grateful > > for the opportunity that was given to me. It is certainly among the > things > > that I am most proud of and I would like to thank everyone who trusted > and > > helped me in this role. > > > > Last but not least, we should discuss who should be the new PMC chair of > > Calcite after I step down in December. I would like to nominate Haisheng > > Yuan as the first candidate in the vote. Apart from many high quality > > contributions, Haisheng has reviewed a big amount of PRs, and led many > > technical discussions to consensus. Haisheng has been in the community > for > > a while and I believe he will be a great chair if he is willing to > accept. > > > > To conclude, I will repeat the questions from previous years: > > > > 1) What else are we doing well in the project? > > 2) What areas do we need to do better? > > 3) Which other candidates should we consider for PMC chair? > > > > Please take some time to share your thoughts! > > > > Note that this discussion is for everyone; even if you have never sent an > > email to the list before now it is a good time to do so :) > > > > Best, > > Stamatis > > > > [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] https://issues.apache.org/jira/browse/CALCITE-3923 > > [4] https://issues.apache.org/jira/browse/CALCITE-3724 > > [5] https://issues.apache.org/jira/browse/CALCITE-2157 > > [6] https://issues.apache.org/jira/browse/CALCITE-3916 > > [7] https://issues.apache.org/jira/browse/CALCITE-3896 > > [8] https://issues.apache.org/jira/browse/CALCITE-3753 > > [9] https://issues.apache.org/jira/browse/CALCITE-2970 > > [10] https://issues.apache.org/jira/browse/CALCITE-482 > > [11] https://issues.apache.org/jira/browse/CALCITE-3510 > > [12] https://issues.apache.org/jira/browse/CALCITE-4034 > > >
