Oh, thanks for reminding me. It seems I missed that discussion (I wasn't involved in Calcite back then).
Then let's continue with this approach. Thank you for your patient explanation. Best wishes Cancai On 2026/04/01 15:05:46 Stamatis Zampetakis wrote: > The person who merged PR#4855 is a calcite committer so it is possible > and accepted to merge a PR without getting an explicit approval by > another committer. > > There are some past discussions on the topic [1, 2] that basically sum up to: > * ask and wait for review when changes are big, important, breaking (RTC) > * push small and low risk changes without waiting for a review (CTR) > > This model has been working well for many years so I don't find it > necessary to change it. > > Best, > Stamatis > > [1] https://lists.apache.org/thread/fsrv3hdck20374y1c9s380h5cxhk6gnf > [2] https://lists.apache.org/thread/x61yz4j4d5820dgbrtynmkzos96x4k36 > > On Wed, Apr 1, 2026 at 4:47 PM Cancai Cai <[email protected]> wrote: > > > > Hi, Stamatis > > > > Okay, perhaps I've been a bit vague. Let me illustrate with an example, > > such as a recent merged PR: > > > > https://github.com/apache/calcite/pull/4855 > > > > This PR didn't have any other committers or PMCs approving it. > > > > Best wishes, > > Cancai. > > > > On 2026/04/01 14:40:08 Stamatis Zampetakis wrote: > > > Hi Cancai, > > > > > > Can you please provide some pointers to the specific PRs? Only > > > committers have write access to the repo so not sure what exactly is > > > the problem you are referring to. > > > Note that in Calcite we don't have a strict RTC policy and for many > > > cases we have been doing CTR. > > > > > > Best, > > > Stamatis > > > > > > On Wed, Apr 1, 2026 at 4:38 PM jensen <[email protected]> wrote: > > > > > > > > Thanks for raising this topic. I think establishing a basic principle > > > > for the Apache Calcite community is necessary. Having multiple > > > > reviewers can help contributors double-check their code, which is a > > > > good practice. As you mentioned, all of Calcite’s contributors are > > > > volunteers, and their time is limited. I believe contributors should be > > > > patient throughout the contribution process. I’m not an expert in all > > > > areas of Calcite, but I’ll continue learning and try to review more > > > > pull requests. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Zhen > > > > > > > > ---- Replied Message ---- > > > > | From | Cancai Cai<[email protected]> | > > > > | Date | 04/01/2026 21:39 | > > > > | To | [email protected] | > > > > | Cc | | > > > > | Subject | Merge PR principles reminder | > > > > I'm not sure if it's appropriate to bring this up, but I feel it's > > > > necessary to raise this point. > > > > > > > > Recently, I've noticed that some pull requests related to Jira issues > > > > have > > > > been merged without approval from committers and PMCs. Some even only > > > > received AI review, without any review from other committers or PMCs. I > > > > think this is unreasonable, and I hope this situation can be reduced in > > > > the > > > > future. > > > > > > > > Calcite is a project without a commercial company behind it, yet it has > > > > still been able to develop healthily for many years, thanks to the > > > > efforts > > > > of everyone in the community. This also demonstrates that Calcite's > > > > community governance policies are sound, and we don't need to break any > > > > fundamental principles. > > > > > > > > Best wishes, > > > > Cancai > > > >
