From adb60cb26186c8ff2f61d8f20a0b2a71a45f68b8 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Petr=20=C5=A0pa=C4=8Dek?= Date: Wed, 10 Apr 2024 16:21:50 -0400 Subject: [PATCH] Remove Gitlab issue templates from non-main branches There is no reason to have templates in branches other than main. Gitlab is not using them anyway and they are unnecessarily included in tarballs. --- .gitlab/issue_templates/Bug.md | 46 ---------- .gitlab/issue_templates/CVE.md | 37 -------- .gitlab/issue_templates/Feature_Request.md | 11 --- .gitlab/issue_templates/Release.md | 98 ---------------------- 4 files changed, 192 deletions(-) delete mode 100644 .gitlab/issue_templates/Bug.md delete mode 100644 .gitlab/issue_templates/CVE.md delete mode 100644 .gitlab/issue_templates/Feature_Request.md delete mode 100644 .gitlab/issue_templates/Release.md diff --git a/.gitlab/issue_templates/Bug.md b/.gitlab/issue_templates/Bug.md deleted file mode 100644 index b2f43e82557..00000000000 --- a/.gitlab/issue_templates/Bug.md +++ /dev/null @@ -1,46 +0,0 @@ - - -### Summary - -(Summarize the bug encountered concisely.) - -### BIND version used - -(Paste the output of `named -V`.) - -### Steps to reproduce - -(How one can reproduce the issue - this is very important.) - -### What is the current *bug* behavior? - -(What actually happens.) - -### What is the expected *correct* behavior? - -(What you should see instead.) - -### Relevant configuration files - -(Paste any relevant configuration files - please use code blocks (```) -to format console output. If submitting the contents of your -configuration file in a non-confidential Issue, it is advisable to -obscure key secrets: this can be done automatically by using -`named-checkconf -px`.) - -### Relevant logs and/or screenshots - -(Paste any relevant logs - please use code blocks (```) to format console -output, logs, and code, as it's very hard to read otherwise.) - -### Possible fixes - -(If you can, link to the line of code that might be responsible for the -problem.) - -/label ~bug diff --git a/.gitlab/issue_templates/CVE.md b/.gitlab/issue_templates/CVE.md deleted file mode 100644 index fc95d55ca00..00000000000 --- a/.gitlab/issue_templates/CVE.md +++ /dev/null @@ -1,37 +0,0 @@ - - -### CVE-specific actions - - - [ ] Assign a CVE identifier - - [ ] Determine CVSS score - - [ ] Determine the range of BIND versions affected (including the Subscription Edition) - - [ ] Determine whether workarounds for the problem exists - - [ ] Create a draft of the security advisory and put the information above in there - - [ ] Prepare a detailed description of the problem which should include the following by default: - - instructions for reproducing the problem (a system test is good enough) - - explanation of code flow which triggers the problem (a system test is *not* good enough) - - [ ] Prepare a private merge request containing the following items in separate commits: - - a test for the issue (may be moved to a separate merge request for deferred merging) - - a fix for the issue - - documentation updates (`CHANGES`, release notes, anything else applicable) - - [ ] Ensure the merge request from the previous step is reviewed by SWENG staff and has no outstanding discussions - - [ ] Ensure the documentation changes introduced by the merge request addressing the problem are reviewed by Support and Marketing staff - - [ ] Prepare backports of the merge request addressing the problem for all affected (and still maintained) BIND branches (backporting might affect the issue's scope and/or description) - - [ ] Prepare a standalone patch for the last stable release of each affected (and still maintained) BIND branch - -### Release-specific actions - - - [ ] Create/update the private issue containing links to fixes & reproducers for all CVEs fixed in a given release cycle - - [ ] Reserve a block of `CHANGES` placeholders once the complete set of vulnerabilities fixed in a given release cycle is determined - - [ ] Ensure the merge requests containing CVE fixes are merged into `security-*` branches in CVE identifier order - -### Post-disclosure actions - - - [ ] Merge a regression test reproducing the bug into all affected (and still maintained) BIND branches diff --git a/.gitlab/issue_templates/Feature_Request.md b/.gitlab/issue_templates/Feature_Request.md deleted file mode 100644 index 9ad28f49ed1..00000000000 --- a/.gitlab/issue_templates/Feature_Request.md +++ /dev/null @@ -1,11 +0,0 @@ -### Description - -(Describe the problem, use cases, benefits, and/or goals.) - -### Request - -(Describe the solution you'd like to see.) - -### Links / references - -/label ~"feature request" diff --git a/.gitlab/issue_templates/Release.md b/.gitlab/issue_templates/Release.md deleted file mode 100644 index 2fd3da81d38..00000000000 --- a/.gitlab/issue_templates/Release.md +++ /dev/null @@ -1,98 +0,0 @@ -## Release Schedule - -**Code Freeze:** - -**Tagging Deadline:** - -**Public Release:** - -## Documentation Review Links - -**Closed issues assigned to the milestone without a release note:** - - - []() - - []() - - []() - -**Merge requests merged into the milestone without a release note:** - - - []() - - []() - - []() - -**Merge requests merged into the milestone without a `CHANGES` entry:** - - - []() - - []() - - []() - -## Release Checklist - -### Before the Code Freeze - - - [ ] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates). - - [ ] ***(QA)*** Ensure there are no permanent test failures on any platform. - - [ ] ***(QA)*** Check charts from `shotgun:*` jobs in the scheduled pipelines to verify there is no unexplained performance drop for any protocol. - - [ ] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released. - - [ ] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1]. - - [ ] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only). - - [ ] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported. - - [ ] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect. - -### Before the Tagging Deadline - - - [ ] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found. - - [ ] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well. - - [ ] ***(QA)*** Update API files for libraries with new version information. - - [ ] ***(QA)*** Change software version and library versions in `configure.ac` (new major release only). - - [ ] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org`. - - [ ] ***(QA)*** Update `CHANGES`. - - [ ] ***(QA)*** Update `CHANGES.SE` (Subscription Edition only). - - [ ] ***(QA)*** Update `README.md`. - - [ ] ***(QA)*** Update `version`. - - [ ] ***(QA)*** Build documentation on `docs.isc.org`. - - [ ] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes. - - [ ] ***(QA)*** Check that the formatting of the generated man pages is correct. - - [ ] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`). - -### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases) - - - [ ] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published. - - [ ] ***(QA)*** Announce (on Mattermost) that the code freeze is over. - - [ ] ***(QA)*** Request signatures for the tarballs, providing their location and checksums. - - [ ] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures. - - [ ] ***(QA)*** Verify tarball signatures and check tarball checksums again. - - [ ] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built. - - [ ] ***(QA)*** Build and test ASN and/or Subscription Edition packages. - - [ ] ***(QA)*** Notify Support that the releases have been prepared. - - [ ] ***(Support)*** Send out ASNs (if applicable). - -### On the Day of Public Release - - - [ ] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable). - - [ ] ***(Support)*** Place tarballs in public location on FTP site. - - [ ] ***(Support)*** Publish links to downloads on ISC website. - - [ ] ***(Support)*** Write release email to *bind-announce*. - - [ ] ***(Support)*** Write email to *bind-users* (if a major release). - - [ ] ***(Support)*** Send eligible customers updated links to the Subscription Edition (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket). - - [ ] ***(Support)*** Update tickets in case of waiting support customers. - - [ ] ***(QA)*** Build and test any outstanding private packages. - - [ ] ***(QA)*** Build public RPMs. - - [ ] ***(SwEng) *** Build Debian/Ubuntu packages. - - [ ] ***(SwEng) *** Update Docker images. - - [ ] ***(QA)*** Inform Marketing of the release. - - [ ] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made. - - [ ] ***(Marketing)*** Post short note to Twitter. - - [ ] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND). - - [ ] ***(Marketing)*** Write blog article (if a major release). - - [ ] ***(QA)*** Ensure all new tags are annotated and signed. - - [ ] ***(QA)*** Push tags for the published releases to the public repository. - - [ ] ***(QA)*** Merge the automatically prepared `prep 9.x.y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_x`). - - [ ] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch. - - [ ] ***(QA)*** Prepare empty release notes for the next set of releases. - - [ ] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public. - - [ ] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2]. - - [ ] ***(QA)*** Update QA tools used in GitLab CI (e.g. Black, PyLint) by modifying the relevant `Dockerfile`. - -[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone. -[^2]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure. -- 2.47.3