We have some blockers to strictly enforce RTC such as having enough volunteer time to provide timely PR reviews along with an unnecessarily long CI build time (especially when building locally with all tests now takes about 15 minutes versus 45 minutes in CI). I think we've mostly settled on using your best judgement on when to request review before merging versus when you can simply commit directly (e.g., why bother waiting for full builds to execute just to fix a docs typo).
On Fri, Apr 15, 2022 at 10:35 AM Gary Gregory <garydgreg...@gmail.com> wrote: > > Note that nothing is preventing people who like RTC to do so. > > Gary > > On Fri, Apr 15, 2022, 09:25 Volkan Yazıcı <vol...@yazi.ci> wrote: > > > I couldn't introduce branch protection (aka. RTC review-then-commit) since > > Gary was strongly against it. It was just me, Matt, and Carter supporting > > the idea; Ralph was also sort of against it. You can search the archives > > for details. > > > > I couldn't even introduce commit signatures. Sigh... > > > > On Fri, Apr 15, 2022 at 5:34 AM Remko Popma <remko.po...@gmail.com> wrote: > > > > > I remember we discussed changing our development process to use PRs > > instead > > > of committing directly to the release branches. > > > This was part of trying to increase our security score, especially the > > > Branch Protection part > > > in scorecard (https://github.com/ossf/scorecard/blob/main/docs/checks.md > > ). > > > > > > Questions: > > > * how many approvals did we agree on before a PR can be merged? > > > * if a PR is merged into release-2.x, can it be cherry-picked onto 3.0 > > > directly, or does the change to the 3.0 branch need a separate PR? > > > * what to do with the updates to changes.xml? Does that need to be > > included > > > in the PRs? > > > > >
