You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iotdb.apache.org by Wang Critas <cr...@outlook.com> on 2025/10/28 10:13:29 UTC
答复: [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 <ch...@c-ware.de>
日期: 星期二, 2025年10月28日 17:54
收件人: dev@iotdb.apache.org <de...@iotdb.apache.org>
主题: 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 <cr...@outlook.com>
Datum: Dienstag, 28. Oktober 2025 um 10:44
An: dev@iotdb.apache.org <de...@iotdb.apache.org>
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 <ch...@c-ware.de>
日期: 星期二, 2025年10月28日 17:37
收件人: dev@iotdb.apache.org <de...@iotdb.apache.org>
主题: 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 dev@iotdb.apache.org 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%7Cc826f69fccb44f15a42e08de1607fac5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638972420696592253%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=spf1Ox00UAbfKKXHfYl%2Fdt8PI5krFWJTC%2B2dERTcF5c%3D&reserved=0<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fgztpm94p7swhk7vto1mynq1rt21xs8hb&data=05%7C02%7C%7Cc826f69fccb44f15a42e08de1607fac5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638972420696615554%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dyfT9LxMitdTNML%2BA5V0MhebhrgIle2O61B9VJK3R2A%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%7Cc826f69fccb44f15a42e08de1607fac5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638972420696631076%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=op5TWJL%2BTfF6OedxzHTNYna471Of8IH35rGiml49gcY%3D&reserved=0<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fyp4yb2oy9745gcqs4mvb4n5916hoz6t5&data=05%7C02%7C%7Cc826f69fccb44f15a42e08de1607fac5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638972420696646476%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FaK29hcENYatJ3Z1pbyJ9UQAl9uyYoKQxv%2F%2FTdgjFQQ%3D&reserved=0><https://lists.apache.org/thread/yp4yb2oy9745gcqs4mvb4n5916hoz6t5>
Chris
Von: Wang Critas <cr...@outlook.com>
Datum: Dienstag, 28. Oktober 2025 um 08:45
An: dev <de...@iotdb.apache.org>
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
Re: 答复: [DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews
Posted by Justin Mclean <jm...@apache.org>.
Hi,
Strengthening code review quality is a good goal, but we should be cautious that it doesn’t become another way to circumvent vendor neutrality.
At Apache, community oversight and openness are what ensure quality. When rules like mandatory multi-review or branch-protection settings are introduced, they can shift that balance. If most reviewers come from the same employer, a “two-review” rule doesn’t actually improve independence; it can just formalise corporate gatekeeping and make it harder for outside contributors to participate.
If the aim is to improve review culture and if that is an actual issue, that’s best handled through community practice, for example:
- Encouraging more than one reviewer for major or risky changes, but keeping the process flexible.
- Ensuring that reviewers, where possible, come from different organisations.
- Documenting this as a recommended approach in CONTRIBUTING.md.
That approach would more likely strengthen both code quality and community health and without undermining independence or the principle that all committers act as individuals, not representatives of their employer.
I suggest the project reflects on the real reasons to why they are introducing this and what problem it solves.
Kind Regards,
Justin
Re: AW: [DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews
Posted by Justin Mclean <jm...@apache.org>.
Hi,
Thanks for raising the idea of strengthening review practices. ASF projects should balance process with inclusiveness. Formal enforcement (such as mandatory two-review rules in GitHub) can unintentionally centralise control, especially if all reviewers come from the same organisation, and can lead to the exclusion of other companies' contributions, both directly and indirectly.
A more community-friendly approach might be to encourage multi-review through project norms, i.e. documenting it in the CONTRIBUTING guide or treating it as a “preferred practice”, rather than enforcing it.
However, Chris is spot on here—the key question is whether there’s been any real issue this change solves. If not, why introduce it?
Kind Regards,
Justin
AW: [DISCUSSION] Proposal: Strengthen Main Branch Protection by Requiring at Least Two Reviews
Posted by Christofer Dutz <ch...@c-ware.de>.
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 <cr...@outlook.com>
Datum: Dienstag, 28. Oktober 2025 um 11:13
An: dev@iotdb.apache.org <de...@iotdb.apache.org>
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 <ch...@c-ware.de>
日期: 星期二, 2025年10月28日 17:54
收件人: dev@iotdb.apache.org <de...@iotdb.apache.org>
主题: 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 <cr...@outlook.com>
Datum: Dienstag, 28. Oktober 2025 um 10:44
An: dev@iotdb.apache.org <de...@iotdb.apache.org>
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 <ch...@c-ware.de>
日期: 星期二, 2025年10月28日 17:37
收件人: dev@iotdb.apache.org <de...@iotdb.apache.org>
主题: 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 dev@iotdb.apache.org 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 <cr...@outlook.com>
Datum: Dienstag, 28. Oktober 2025 um 08:45
An: dev <de...@iotdb.apache.org>
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