On Fri, Apr 4, 2025 at 4:07 AM Volkan Yazıcı <vol...@yazi.ci> wrote: > > On Wed, Apr 2, 2025 at 7:12 PM 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 > > >
Abstain. > > > > Vote 2. Require conversation resolution before merging: > > [ ] +1, enable this feature > > [ ] -1, do not enable this feature > > > Abstain. > > > > 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 > > > -1 While I usually squash all PRs, sometimes a PR contains worthwhile "steps", like one commit for cleaning up something while the real fix is a focused commit. So requiring this is silly as a general rule IMO. You could argue that the cleaning up commit or the changes that are not directly related should in a different PR, but then that's even more noise. This vote items conflates two topics I think: (1) merge commits (a pain), and (2) PRs with multiple commits (can be good). > > All major F/OSS projects work like this, including OpenJDK. A majority of > PRs contain several noise commits; "apply review suggestions", "redo > stuff", "fix typos", etc. They bring no value but pollute the history. > Plus, `cherry-pick`ing and `revert`ing merge PRs are more difficult > compared to squashed ones. Gentlemen, *please please please squash your > commits before merging a PR!* > > > > Vote 4. Require status checks to pass before merging: > > [ ] +1, enable this feature > > [ ] -1, do not enable this feature > > Abstain. The "status checks" are not defined in this vote. > > +1 > > Even though it sounds nice, there were several occasions in the past where > the CI is broken for all jobs, or for some particular platform, etc. > > > > Vote 5. Require at least one positive review before merging: > > [ ] +1, enable this feature > > [ ] -1, do not enable this feature Abstain. Gary > > > > +999 (Assuming you meant "Approval" with "positive review".)
