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://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fgztpm94p7swhk7vto1mynq1rt21xs8hb&data=05%7C02%7C%7C3801baec2df345b90c8508de16059043%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638972410322125149%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BdL7fDeUKUtQR8HV3eHXiOzjJfZYixIhUqIbRDycv%2F0%3D&reserved=0<https://lists.apache.org/thread/gztpm94p7swhk7vto1mynq1rt21xs8hb>
https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fyp4yb2oy9745gcqs4mvb4n5916hoz6t5&data=05%7C02%7C%7C3801baec2df345b90c8508de16059043%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638972410322146578%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vHs4kjeTPtZLQDglHd%2FnXPhyDP5Jei51oJptQg3yNi0%3D&reserved=0<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

Reply via email to