Hehe, If you are asking me, as someone who cares deeply about Apache, its core values and vendor neutrality. I would say: Having at least two reviews from people employed by different companies would reduce my „gatekeeping“ fears. During my time as a Director, I’ve just seen to many other projects with patterns that seemed to be „corporate gatekeeping“.
But still … what issues did we have in the past, that would want us to put these rules in place? If it’s just education and reducing the bus-factor, Timecho or the Tsinghua University could simply say: For educational purposes, we want at least two of our people to review things. I am fearing a bit, that even if the intention is to spread knowledge, mostly one person will do the review and then someone else will simply waive it through. So, IF we did this, I would expect each of the reviewers to document what they did to review and not allowing simple „+1“ approvals. Chris Von: Wang Critas <[email protected]> Datum: Dienstag, 28. Oktober 2025 um 11:13 An: [email protected] <[email protected]> Betreff: 答复: [DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews Hi, Thank you for raising this important point about keeping the barrier for contributors low. I agree that this is a critical principle for a healthy open-source community. I also share your concern about not creating unnecessary hurdles. The goal isn't to add bureaucracy, but to encourage a more inclusive review culture. Ideally, this would involve more community members in the review process, spreading knowledge and reducing bus factor, rather than concentrating approval power. Your feedback rightly moves the discussion from “if we should do this" to “how we could do it well." What are your thoughts on these ideas? Additionally, the "two-person" rule means that in addition to the PR author, at least one other reviewer is required. I’m unsure if this can be directly configured this way. Xuan 发件人: Christofer Dutz <[email protected]> 日期: 星期二, 2025年10月28日 17:54 收件人: [email protected] <[email protected]> 主题: AW: [DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews HI, I just wanted to take the opportunity to also bring up the other topic again, as I don’t understand why we voted clearly on it and nothing has happened and no explanation why nothing has happened. But regarding your question: When mentoring projects, I always give one piece of advice: "Put up as few rules and restriction and only put up rules that you actually need" So … I would like to ask: What actual problem that we are having would this solve? I can imagine theoretical problems, but have we had real problems? I haven’t heard of anything on this list. Rules like this also raise the barrier for people outside of the „core team" to get changes in, so without real problems I would actually be hesitant to approve such a change. Chris Von: Wang Critas <[email protected]> Datum: Dienstag, 28. Oktober 2025 um 10:44 An: [email protected] <[email protected]> Betreff: RE: [DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews emm..., This email serves as a brief supplement to my previous proposal [[DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews], sent earlier. I would like to clarify the scope of the term "main branches" used in my proposal. It was intended to encompass all long-lived, critical branches that serve as the core integration line for development, such as: * main * master (Current use) * develop The core idea is to ensure that any branch serving as the primary base for releases or major development streams benefits from the increased robustness of a multi-reviewer process. The goal is not to restrict this practice to a branch named mainspecifically. This clarification aims to ensure we have a common understanding when discussing the proposal. Thank you for your attention. Xuan Wang 发件人: Christofer Dutz <[email protected]> 日期: 星期二, 2025年10月28日 17:37 收件人: [email protected] <[email protected]> 主题: AW: [DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews Hehe … I think we don’t have a „main“ branch. We only have „master“ I still have the email of the vote we had here 12.10.2020 pinned to the top of the [email protected] folder, where we actually decided to switch to „release“ and „develop“ but nothing’s happened since then 😉 https://lists.apache.org/thread/gztpm94p7swhk7vto1mynq1rt21xs8hb<https://lists.apache.org/thread/gztpm94p7swhk7vto1mynq1rt21xs8hb><https://lists.apache.org/thread/gztpm94p7swhk7vto1mynq1rt21xs8hb> https://lists.apache.org/thread/yp4yb2oy9745gcqs4mvb4n5916hoz6t5<https://lists.apache.org/thread/yp4yb2oy9745gcqs4mvb4n5916hoz6t5><https://lists.apache.org/thread/yp4yb2oy9745gcqs4mvb4n5916hoz6t5> Chris Von: Wang Critas <[email protected]> Datum: Dienstag, 28. Oktober 2025 um 08:45 An: dev <[email protected]> Betreff: [DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews Hi all, I hope this message finds you well. I am writing to propose an enhancement to our current main branch protection rules in the IoTDB repository. Specifically, I suggest modifying the branch protection settings to require at least two approving reviews from contributors before code can be merged into the main branch. Why This Change? 1. Improved Code Quality: Multiple reviews help catch issues—such as logical errors, edge cases, or performance regressions—that might be overlooked in a single review. This aligns with Apache Software Foundation’s emphasis on collaborative quality assurance. 1. Knowledge Sharing: Encouraging more reviewers fosters broader understanding of code changes across the team, reducing bus-factor risks. 1. Community Inclusivity: Involving more contributors in reviews promotes mentorship and aligns with Apache’s "Community Over Code" principle. Current Gap While the main branch may already have some protection, the absence of a mandatory multi-reviewer step could allow potential issues to slip through, especially for complex changes. Proposed Implementation * Update branch protection rules (e.g., in GitHub) to require ≥2 approvals. * This practice is common in ASF projects has proven to reduce integration risks. I believe it would strengthen IoTDB’s reliability as it evolves toward cloud-native and edge scenarios . I welcome feedback and would be happy to help implement the change. Best regards, Xuan Wang
