|
|
## Repository
|
|
|
### Repository
|
|
|
|
|
|
The authoritative source for the main repository will be:
|
|
|
|
|
|
* SSH Access: [git@gitlab.isc.org:BIND/bind9.git](git@gitlab.isc.org:BIND/bind9.git)
|
|
|
* HTTPS Access: [https://gitlab.isc.org/BIND/bind9.git](https://gitlab.isc.org/BIND/bind9.git)
|
|
|
|
|
|
## Private Repository
|
|
|
### Private Repository
|
|
|
|
|
|
The private repository for security updates will be:
|
|
|
|
|
|
<private_url>
|
|
|
|
|
|
## What happens to repo.isc.org
|
|
|
### What happens to repo.isc.org
|
|
|
|
|
|
We will keep it untouched.
|
|
|
|
|
|
## What about Tinderbox updates?
|
|
|
### What about Tinderbox updates?
|
|
|
|
|
|
This will be eventually replaced by GitLab CI.
|
|
|
|
|
|
## Naming scheme for branches
|
|
|
### Naming scheme for branches
|
|
|
|
|
|
I propose that instead of nameless rt<number> we use descriptive names for branches, like "refactor-update-sigs". They will be given numeric evidence when you create Merge Request from the branch.
|
|
|
|
|
|
## What protocol are we going to use for handling discussions?
|
|
|
### What protocol are we going to use for handling discussions?
|
|
|
|
|
|
There are couple of options related to [discussions](https://docs.gitlab.com/ce/user/discussions/).
|
|
|
|
... | ... | @@ -33,11 +33,11 @@ If there are major issues that can't / shouldn't be resolved from current merge |
|
|
|
|
|
Otherwise anybody (with Developer status) can resolve discussion if he or she thinks the discussion has been resolved.
|
|
|
|
|
|
## Who should trigger the final merge
|
|
|
### 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?
|
|
|
### Is `git push -f` considered harmful?
|
|
|
|
|
|
Depends.
|
|
|
|
... | ... | @@ -45,10 +45,10 @@ We will use [protected branches](https://docs.gitlab.com/ce/user/project/protect |
|
|
|
|
|
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?
|
|
|
### 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 merge request?
|
|
|
### How to backport merge request?
|
|
|
|
|
|
After the merge request is merged there's an option to use the same commits to create new merge request on different branch. Generally, this approach should be used. |