mirror of
https://github.com/isc-projects/bind9.git
synced 2026-06-16 22:38:53 -04:00
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.
This commit is contained in:
Petr Špaček
parent
73defe8aac
commit
adb60cb261
4 changed files with 0 additions and 192 deletions
|
|
@ -1,46 +0,0 @@
|
|||
<!--
|
||||
If the bug you are reporting is potentially security-related - for example,
|
||||
if it involves an assertion failure or other crash in `named` that can be
|
||||
triggered repeatedly - then please do *NOT* report it here, but send an
|
||||
email to [security-officer@isc.org](security-officer@isc.org).
|
||||
-->
|
||||
|
||||
### 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
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
<!--
|
||||
THIS ISSUE TEMPLATE IS INTENDED ONLY FOR INTERNAL USE.
|
||||
|
||||
If the bug you are reporting is potentially security-related - for example,
|
||||
if it involves an assertion failure or other crash in `named` that can be
|
||||
triggered repeatedly - then please do *NOT* report it here, but send an
|
||||
email to [security-officer@isc.org](security-officer@isc.org).
|
||||
-->
|
||||
|
||||
### 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
|
||||
|
|
@ -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"
|
||||
|
|
@ -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.
|
||||
Loading…
Reference in a new issue