OK. With the new descriptions I can vote on this. > On Apr 2, 2025, at 10:12 AM, Piotr P. Karwasz <pi...@mailing.copernik.eu> > 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
