Re: merging PRs - branch protection questions
Somehow I replied on the wrong thread. I was OK with requiring PRs that I could self approve. I was not OK with requiring every PR require multiple approvals. Ralph > On Apr 15, 2022, at 3:24 PM, Volkan Yazıcı 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 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? >>
Re: merging PRs - branch protection questions
Thanks for the heads up Matt! Have done it. On Fri, Apr 15, 2022 at 8:37 PM Matt Sicker wrote: > Volkan, if you'd like to continue using git commit sigs, you should > also upload your public GPG key to your GitHub account so that it can > verify your commits, too. Otherwise, GitHub doesn't exactly import GPG > keys from the public web of trust; they only use GPG keys you specify > in your profile (whereas they do support X.509 keys when certified by > a public CA, but this feature seems a lot more recent than the GPG > support). > > On Fri, Apr 15, 2022 at 8:25 AM Volkan Yazıcı 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 > 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? > > > >
Re: merging PRs - branch protection questions
Volkan, if you'd like to continue using git commit sigs, you should also upload your public GPG key to your GitHub account so that it can verify your commits, too. Otherwise, GitHub doesn't exactly import GPG keys from the public web of trust; they only use GPG keys you specify in your profile (whereas they do support X.509 keys when certified by a public CA, but this feature seems a lot more recent than the GPG support). On Fri, Apr 15, 2022 at 8:25 AM Volkan Yazıcı 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 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? > >
Re: merging PRs - branch protection questions
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 wrote: > > Note that nothing is preventing people who like RTC to do so. > > Gary > > On Fri, Apr 15, 2022, 09:25 Volkan Yazıcı 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 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? > > > > >
Re: merging PRs - branch protection questions
Note that nothing is preventing people who like RTC to do so. Gary On Fri, Apr 15, 2022, 09:25 Volkan Yazıcı 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 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? > > >
Re: merging PRs - branch protection questions
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 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? >
