Reviewing & merging Pull Requests

[slspencer]

Our repo workflow is to allow others to review and approve Pull Requests before they are merged. It isn't good practice for developers to merge their own PRs.

The exception is for CI/CD build pipeline PRs -- These MUST be merged because they are only executed on a build; the tests that run when a Pull Request is created exclude the build pipeline. These CI/CD PR merges are easily rolled back if they fail to achieve desired results. The developer can merge their own CI/CD PRs in order to quickly make changes as needed.

[slspencer]

New thoughts on PRs that affect our GH Actions CI/CD build pipeline:

It's been previously suggested that to implement new GH Actions that require extensive testing, we should create a feature branch, create a new GH Action to build that branch. and then run tests of updates to the GH Action to prevent 'spammy' notificaitons of new builds, failures, etc.

[csett86]

I suggest to treat PRs that affect the CI pipeline the same as code changes. As part of the PR, the CI build is anyway executed on all platforms and build results are archived and can be downloaded from github actions and locally tested if the result still runs.

I used this successfully eg for the 32-bit windows CI implementation in #916 or the ubuntu upgrade in #866