I'd be on board with this. It might be worth having some rule that if a committer's PR goes unreviewed for over a certain period of time, then the committer can just merge the PR after it passes the automated checks. I don't want this project's development to end up stalled because everyone is either too busy or too inexperienced to review PRs from each other, but I'd love for us to use a better UI for doing these reviews in the first place.
On a related note, it'd be great if PRs and commits didn't generate like 3+ duplicate emails each. On Wed, Jan 26, 2022 at 3:40 PM Carter Kozak <cko...@ckozak.net> wrote: > > I'd love to start using the github PR workflow for our contributions. I've > been using them for my changes for a while and find it much easier than > running a full build locally to verify each change on my development system. > While we've historically used "commit then review", I find it much easier to > consolidate review and discussion on pull requests, which results in cleaner > history, and clearer historical context in one place when changes are > requested. The downside is that it means merging changes is blocked on other > committers, so we must be cognizant of that when PRs are opened, keeping a > balance of timely reviews and patience. > > While this isn't an issue for our own changes, we may need to figure > something out to improve the experience of adding changelog entries for > third-party contributions, however those are a minority and I wouldn't block > on solving that problem. > > Carter > > On Wed, Jan 26, 2022, at 15:25, Volkan Yazıcı wrote: > > According to the OSSF Scorecards <https://github.com/ossf/scorecard>, we > > are missing two check marks (LOG4J2-3260 > > <https://issues.apache.org/jira/browse/LOG4J2-3260>) there: > > > > 1. Require code review (every change goes into a PR and requires at > > least one reviewer) > > 2. Require a CI status check > > > > Even though I admit with the convenience of freedom we have right now, I > > personally find it difficult to keep track of what is going in and out. > > This convention does not aim to obstruct the development progress, but > > rather improve the overall code quality and spread the know-how in a > > scalable way. Hence, I want to implement this feature on `release-2.x` and > > `master` branches. Thoughts? > > >
