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/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
