# Merge with git instead of github UI

If someone sends patches by email apply them on top of latest master, and

push to upstream. Github pull requests are best to get as extra remote

repositories to your working clone, where commits can be rebased, tidied up,

and so on, before pushing to upstream.

See also https://github.com/iputils/iputils/issues/155

# Do not steal contributions

Use git commit --author 'Contributor <email>' when receiving changes that

are not applicable as-is. Not stealing contributions applies even if change

has to be worked out, that is common case with commit message.

Exception to this rule is a change that is a good idea, but has to be

completely rewrote to be acceptable for the project. In this case

maintainer should attribute the person who gave the idea in commit message.

# Use references in commit messages

For example when a change fixes a distribution bug add link to the bug

report. Links to reference materials can also be useful when in future

trying to understand why something was done. It is also nice when commit id

of the change that caused a bug is referred in commit message. That helps

understanding what versions are impacted by an issue.

# How to make a release

Go to release listings https://github.com/iputils/iputils/releases and check

what was said in previous release message. Draft release message - remember

if you have nothing to say then you don't have good enough reason to publish

release.

Create release commit and tag.

date_str=$(date +s%Y%m%d) &&

sed --in-place "s/version : '.*')/version : '$date_str')/" meson.build &&

git add meson.build &&

git commit --signoff --message "release: iputils-$date_str" &&

git tag --sign --annotate $date_str --message iputils-$date_str

Check that the commit and tag looks ok.

git show $date_str --show-signature

Assuming things are great push to github.

git push origin master:master &&

git push origin --tags

Go to github https://github.com/iputils/iputils/releases and paste the

release message you drafted earlier to text box. Choose the tag you just

created. Download the release files and sign them.

for file in iputils-$date_str ; do gpg --sign --armor --detach-sign $file ; done

Upload the .asc files to release as additional files. The release should be

ready. People tend to react to releases, so expect bug reports and pull

requests after release. Assuming release has fatal flaw(s) make another one

sometime soon.

# Branches in git

The upstream repository has exactly one branch and it is `master`. If a

maintainer wants to use work in progress branches they need to be kept in

personal clone. There are two reasons to do this. For contributors it is

nice not to see random branches when cloning upstream repo. Secondly when

maintainer wants to add a contributor repo as additional remote it is easier

to see what is going on there.