Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
BIND
BIND
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 637
    • Issues 637
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 104
    • Merge Requests 104
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • ISC Open Source Projects
  • BINDBIND
  • Wiki
  • best practices

Last edited by Michał Kępień Feb 20, 2018
Page history

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:

  1. If the MR has related issue, then the branch name would be <issue>-<short description>.
  2. 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)
  3. 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.

Clone repository
  • BIND 9 F2F Meeting in Warsaw, October 2019
  • BIND 9 PKCS11
  • BIND 9 Packaging
  • BIND 9.11 ESV Soft Code Freeze
  • BIND 9.15 Plan
  • BIND 9.17 Plan
  • BIND Development and Release Process 2019
  • BIND development workflow
  • Backporting a Merge Request
  • CVSS Scoring Guidelines
  • DNSSEC Key and Signing Policy (KASP)
  • Debian Packages
  • DoH
    • DOH and DoT Design
  • Formatting test scratchpad.
  • GSOC 2019
View All Pages