Merge branch 'pspacek/gitlab-cleanup' into 'bind-9.18'
Remove Gitlab issue templates from non-main branches See merge request isc-projects/bind9!8943
This commit is contained in:
Petr Špaček
@@ -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.
|
||||
Reference in New Issue
Block a user