As a beginning contributor, it is far from obvious where to find tests,
how to run individual tests locally for quick development, and which
tests do what. The new "Testing changes" section aims to help with all
of these.
Co-authored-by: Emily <git@emilylange.de>
The transition to markdown is done now and the historical trivia is not
helpful for first time contributers who are the primary audience for
this document. Telling the user to edit a file by editing a file is
superfluous.
This change improves the recommendation for good commit messages to
include release notes on package bumps.
Including the release notes increases the likelihood that they will be
taken into consideration during review. Having them included in the
review is important to be able to judge whether changes made during a
version bump are sensible, sufficient or complete.
The burden of retrieving the release notes for arbitrary package bumps
should not rest on the relatively small group of reviewers.
Signed-off-by: Martin Weinelt <hexa@darmstadt.ccc.de>
Makes the instructions easier to remember (and type) using the
`git rebase --onto A...B` syntax to find the merge base between A and B
(which has been in git for at least 10 years).
We also assume that the merge base between staging and master is also
the merge base between staging and the current branch (since it is based
on master), and giving master as the <upstream> branch makes git
consider the commits in the current branch that are not in master, so
there's no need to compute the merge base between master and the current
branch.
In the same spirit of discouraging copy-and-paste, use a placeholder
name for the current branch instead of `$(git branch --show-current)`.
