It's a good idea to use test branches in maven-studies to check the
rules. I'd like to go a step further. I think that we should pick a
repository and apply a certain rule to it.
We can see if this rule works for us in real life.
If not, the change can be reversed. If it is successful, we can roll out
the rule to other repositories.
Sandra
Am 02.08.25 um 23:15 schrieb Hervé Boutemy:
thanks a lot Piotr for this return on experience: this help me a lot
anticipating reality vs theory!
this makes me feel we should try on maven-studies.git = the perfect location to
do stupid tests
I'll have a look at how things are configured in Log4j2 and try to play with
test branches in maven-studies
please others don't hesitate to test for yourself what we can implement vs what
we dream then reading OpensSSF Scorecard and other best practices
Regards,
Hervé
On 2025/08/01 07:18:36 "Piotr P. Karwasz" wrote:
Hi Hervé,
On 30.07.2025 19:02, Hervé Boutemy wrote:
for "Require at least 1 reviewer for approval before merging", IIUC it
combines 2 steps:
- reject direct commits to maintenance branches: require use of PR + merge
- and PR requires more than self review
I'm not absolutely against, just dislike:
1. the overhead
2. the bad habits this will promote
3. it will break maven-release-plugin process that commits directly to
maintenance branch
explanation:
1. overhead of for PR + merge: on simple typos, i'll have in addition to
select a PR label to NOT list the PR in the release notes
2. bad habits:
requiring review even on simple typos, I will find a buddy to quickly pair
review everything small I do (in the same timezone as me, and we'll help each
other at reviewing quickly)
The bad habit comes here: my buddy will quickly review everything, small or
big...
3. if someone wants to add new features and clarify new steps in the release
process
We had a very similar discussion in the Apache Logging project when we
introduced RTC last year [1], which we formally adopted in April [2].
Even if I was the one to push the issue, I was really scared initially
that I “killed Log4j” after realizing that many of the +1 voters weren’t
available to review PRs. Even the PR that enforced RTC was strongly delayed.
However, since then I’ve since grown more confident and satisfied with
how it works in practice:
- My “PR buddy” may not be able to approve PRs immediately, but we have
regular video syncs to go through open issues and reviews.
- The `2.x` branch is much cleaner, no longer cluttered with
micro-commits that more often than not weren’t ported to `main`.
- Copilot in the IDE is great at introducing typos. Ironically, Copilot
as a reviewer catches the typos that were introduced.
- The workflow encourages broader community involvement. I can more
easily ask a contributor to fix a one-liner, so I can retain the ability
to review their fixes.
- We can enable auto-merge now. That way, once approved, we don’t have
to wait for tests to finish to merge a PR manually.
About the overhead for typo fixes:
- I’ve seen plenty of “just a typo” commits break things. Because
they’re small, people don’t always scrutinize them, but a second pair of
eyes could have caught those errors.
- The overhead encourages batching. Instead of opening a PR for a single
typo, you can accumulate fixes in a branch and open one PR when it makes
sense.
- And of course, reviewing a one-liner typo is about a 10-second task.
The effort is proportional to the change.
Regarding release process disruptions:
You're absolutely right: this is one of the areas where RTC still feels
clunky. In Log4j, we create unprotected `release/x.y.z` branches. To
prevent long round trips, changes there are not submitted via PR. But I
strictly limit those to documentation or changelog updates.
After the release, that branch is merged back into `main`, helping us
catch and correct any issues that slipped in.
Best regards,
Piotr
References:
[1] https://lists.apache.org/thread/6gbos0rn3k4y3wjb1hcgnnols4ogqckl
[2] https://lists.apache.org/thread/8ffdw1zqrvwrsdr0ng0m2rgtdnpzg4hk
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
