Using pull requests for all code changes

[scop]

Now that we have more people actively involved, let's start using pull requests for all code changes.

I think I'd also like to switch to using merge commits instead of rebasing, but extra/make-changelog.py likely wouldn't do a too good job with that. We should probably switch also to some other tooling for generating the changelogs, I bet a bunch of ready made applicable ones exist as/if we're moving towards using conventional commits commit messages (should document that in CONTRIBUTING.md BTW, and likely add a commitlint pre-commit check).

Thoughts?

[akinomyoga]

It's already been 3.5 years since we started to operate the maintenance in this way, i.e., we always use pull requests. It's been working without any issues until now. I thought we might close this GitHub discussion as well. In the future, we might need to think about it again when any maintainers become too busy to review PRs, but it is fine for now.

I think I'd also like to switch to using merge commits instead of rebasing,

I completely forgot about this discussion. In the GitHub user interface, there are three ways to merge a PR: to create a merge commit, to rebase commits on top of the latest base branch, and to squash everything in a single commit.

Personally, I've been using

• a merge with a merge commit, when the PR has multiple "properly separated" commits where each commit has its own purpose, and when relevant changes are not scattered in different commits, or
• a squash merge, when the PR has only one commit or unseparated commits.

I feel @scop has been choosing the merge type somewhat in a similar way, but I'm not sure if that is on purpose.

but extra/make-changelog.py likely wouldn't do a too good job with that. We should probably switch also to some other tooling for generating the changelogs, I bet a bunch of ready made applicable ones exist as/if we're moving towards using conventional commits commit messages

We currently use release-please for this purpose.

(should document that in CONTRIBUTING.md BTW, and likely add a commitlint pre-commit check).

I think we already added them.

[scop]

Yeah, I intentionally do merge commits and other types for the stated reasons. I rebase-merge single commit PR's though instead of squashing, but the distinction makes little if any difference for them.