[VOTE] Add branch protection rules to Log4j

[Piotr P. Karwasz]

Hi all,

Trying to implement the RTC rules we discussed in September[1] I 
encountered some problems due to the limitations of the currently 
available GitHub Settings. This is a vote to decide whether or not 
enable certain branch protection features on the code branches (`2.x` 
and `main`) of these repos:


* l-admin * l-jdk * l-jmx-gui
* l-log4j2 * l-log4j-jakarta * l-log4j-kotlin * l-log4j-samples* l-log4j-scala 
* l-log4j-transform * l-log4j-tools * l-parent
* l-slf4j
(i.e. all the Java repos except Chainsaw, Flume and Log4j Audit). The 
vote will be open for 176 hours (1 week). Everybody can vote, but only 
binding votes will be counted. It will concern the following features 
separately: Require a pull request before merging:

[ ] +1, enable this feature
[ ] -1, do not enable this feature
Require conversation resolution before merging:

[ ] +1, enable this feature
[ ] -1, do not enable this feature
Require linear history (Prevent merge commits from being pushed to code branches. Only "Squash" 
and similar allowed): [ ] +1, enable this feature

[ ] -1, do not enable this feature
Require status checks to pass before merging:

[ ] +1, enable this feature
[ ] -1, do not enable this feature

Require at least one positive review before merging:

[ ] +1, enable this feature
[ ] -1, do not enable this feature

Piotr

[1] https://lists.apache.org/thread/6gbos0rn3k4y3wjb1hcgnnols4ogqckl

Re: [VOTE] Add branch protection rules to Log4j

[Ralph Goers]

OK. With the new descriptions I can vote on this.

> On Apr 2, 2025, at 10:12 AM, Piotr P. Karwasz  
> wrote:
> 
> Hi all,
> Sorry, my e-mail client reformatted some lines.
> So, the concerned repos are all non-dormant Java repos: l-admin, l-jdk, 
> l-jmx-gui, l-log4j2, l-log4j-jakarta, l-log4j-kotlin, l-log4j-samples, 
> l-log4j-scala, l-log4j-transform, l-log4j-tools, l-parent.
> 
> Vote 1. Require a pull request before merging:
> [ ] +1, enable this feature
> [ ] -1, do not enable this feature

+1 - in the past we required a Jira issue for every commit. Replacing that with 
a PR seems reasonable. The only downside to this is we were able to have a 
single Jira issue that encapsulated multiple dependency upgrades. Dependabot 
does them all individually.

> 
> Vote 2. Require conversation resolution before merging:
> [ ] +1, enable this feature
> [ ] -1, do not enable this feature

+1

> 
> Vote 3. Require linear history (Prevent merge commits from being pushed to 
> code branches. Only "Squash" and similar allowed):
> [ ] +1, enable this feature
> [ ] -1, do not enable this feature

+0 Sometimes I prefer seeing all the commits and sometime not. It depends on 
what it is.

> 
> Vote 4. Require status checks to pass before merging:
> [ ] +1, enable this feature
> [ ] -1, do not enable this feature

+1 If they exist they should succeed.

> 
> Vote 5. Require at least one positive review before merging:
> [ ] +1, enable this feature
> [ ] -1, do not enable this feature

-.5 - I would agree with this for many PRs but there are quite a few that I am 
fine reviewing after the merge.

Ralph