best practices

Repository

The authoritative source for the main repository will be:

SSH Access: git@gitlab.isc.org:BIND/bind9.git
HTTPS Access: https://gitlab.isc.org/BIND/bind9.git

Private Repository

The private repository for security updates will be:

<private_url>

What happens to repo.isc.org

We will keep it untouched.

What about Tinderbox updates?

This will be eventually replaced by GitLab CI, or outdated.

Naming scheme for branches

Every branch should follow a simple schema:

<issue_no>-

The protocol is simple:

If the MR has related issue, then the branch name would be <issue>-<short description>.
If the MR doesn't have related issue, and it should have an issue (upon developers discretion), then developer creates the issue and follow 1)
If the MR doesn't need related issue (simple things), then you the branch name would be na-<short description>.

What protocol are we going to use for handling discussions?

There are couple of options related to discussions.

Most of the time, we will be using option to automatically resolve discussion when they become outdated by commiting a fixed version.

If there are major issues that can't / shouldn't be resolved from current merge request, the new issue should be created from unresolved discussions.

Otherwise anybody (with Developer status) can resolve discussion if he or she thinks the discussion has been resolved.

Who should trigger the final merge

Generally, the fastest and easiest way is for reviewer to trigger the merge after the review for simple merge requests, and the original submitter to trigger the merge for more complex merge requests (usually the ones reviewed by more people).

Is `git push -f` considered harmful?

Depends.

We will use protected branches feature to prevent force pushing to branches that are public facing (like a version branches).

Other branches might be force pushed at convenience of the people that work on the feature branch. We are small team and we generally know who is cooperating on the branch, so we could just let each other know that you are planning rebasing (squashing, reordering commits, etc.) the branch and force pushing.

Do we delete branches after the final merge?

Yes, we do. With non-squashed merges, it doesn't add any (historical) value to keep the branches around, and gitlab can automatically delete the branch after the merge.

How to backport a Merge Request?

See the relevant article.