On 30/05/20 18:52, Thomas Heigl wrote:
PR approvals on GitHub is a relatively new thing and there is no strict
rule about it. As empiric rule we try to get the approval from (at
least) a couple of other commiters. But it also depends on the
complexity of the PR, and for those who might have a bigger impact on
framework it's good to involve other people on the @dev list.
Do we have any guidelines regarding the development workflow? E.g.
- How many approvals do I need for merging a PR?
PR should come with a Jira issue to track them. The change log is
automatically generated during the release process using the 'Fix
Version' parameter of the issues. For example this is the current change
log for for the upcoming 8.9.0 version
- Who manages the changelog? Should a changelog entry be part of every PR?
This is usually asked in the @dev list, depending on the importance of
the PR (ex: is a fix or a new feature?) and its feasibility (ex: can be
easily / safely back-ported?)
- How do we decide what PRs to backport to older versions?
If I remember correctly GitHub should provide some kind of support for
PRs CI, but I never explored this feature, maybe Martin did something
And are there CI builds for PRs? I would feel more confident clicking the
merge button if there was a CI status check connected to GitHub (and
possibly a Sonarqube check as well).
Your are welcome!