BIND development workflow

Notes from the group meeting during IETF 101:

Use of public and private Gitlab repositories

Handling security incidents

1. Mark security related issues as "confidential" in Gitlab.
2. In your local repository, create a development branch and a test case branch. Branches whose names contain the string "security" anywhere in the name, or end with the string "-testcase", are always protected and cannot be pushed to the isc-projects/bind9 repository. After creating these branches, optionally set the upstream to the isc-private/bind9 repository.
3. While the CVE is in progress, add protection for *_patch* branches and *_P* tags. This can be removed after public disclosure of the CVE, and ensures we will not accidentally release code prior to the planned disclosure date.
4. Once the branches containing the fix(es) and the test case are complete, push them to isc-private/bind9 for review.
5. Create two merge requests, one for each branch pushed in the previous step, so that they can be discussed. Make sure that the destination branch for both of these merge requests is set to master in isc-private/bind9, not isc-projects/bind9.
6. Update the master branch in isc-projects/bind9 with a placeholder CHANGES note.
7. When the fix has been reviewed, cherry-pick it into a separate branch for each fixed maintenance branch (*-security-*-v9_12, *-security-*-v9_11, etc.) These can only be pushed to isc-private/bind9.
8. As the public master and v9_X branches are updated, continually rebase the private *-security-* branches.
9. After disclosure, remove the protection on *_patch* branches and *_P* tags. Merge *-security-* branches to the relevant branches in isc-projects/bind9. Push the *_patch* branches and *_P* tags to isc-projects/bind9. Delete the *-security-* branches from isc-private/bind9.

Maintaining supported preview branches

Supported preview branches are maintained in the isc-private/bind9 repository, and are protected so they cannot be pushed to isc-projects/bind9. The branchsync script keeps them up to date by automatically cherry-picking changes from the associated v9_X branches.

Creating a merge request

Generally, issues are used for discussion of problems and merge requests are used for discussion of the specific code used to fix the problems.

While it is possible to create a merge request and a git branch from the issue page, this isn't recommended. It clutters the MR list with merge requests that have no work in them yet, and also triggers an unnecessary pipeline run. Instead, when working on a Gitlab issue, create a development branch in your local working repository. If you give the branch a name beginning with the issue number followed by a hyphen, then the branch will automatically be associated with that issue when pushed. When ready, push the branch to isc-projects/bind9, then create a merge request to go with the branch. One way to do this is to go to the pipelines page, click on the branch name, and then click "Create merge request". Edit the commit message as necessary, and check "Remove source branch when merged".

For minor changes, it isn't always necessary to create an issue in Gitlab; just create and push a branch, then create a merge request without linking to an issue.

Review labels

Several review-related labels have been added to Gitlab merge requests:

1. Review: Set by the author when the branch is ready to be reviewed.
2. Merge OK: Set by the reviewer when the code is okay.
3. Needs cleanup: Can be set by either the author or the reviewer; this indicates that regardless of the current state of the code, the branch still needs to be cleaned up -- for example, by squashing commits in git rebase -i.
4. Author merge: The author wishes to merge this branch personally and requests that no one else click the merge button, regardless of whether it's deemed ready.