CANDLEPIN-1126: Update issue tracker from Bugzilla to Jira

_data/toc.yaml

@@ -130,7 +130,7 @@
         subs:
           - section: cleanup_db_backup
       - section: building_rpms_with_tito
-      - section: bugzilla_process
+      - section: jira_process
       - section: standard_for_card_sizes
   - section: reference
     subs:

docs/candlepin/developers.md

@@ -34,9 +34,8 @@ The first line of a commit message is used as the title for many things, includi
 and the default PR title. Commit titles are limited to 70 characters and will be automatically truncated or
 word-wrapped by tooling the processes commit messages.
 
-For commits originating from publicly viewable tasks (only Bugzilla as of October, 2022), the beginning of the
-commit title should be the ID of that task followed by a colon. When Jira becomes publicly accessible, the
-Jira task ID should be included as well.
+For commits originating from jira issues, the beginning of the
+commit title should be the ID of that issue followed by a colon (e.g. CANDLEPIN-XYZ: ).
 
 The body of the commit message should consist of one or more bulleted items indicating specifics about the
 change, such that a reader unfamiliar with the specifics of the change can get a rough understanding of the
@@ -51,14 +50,12 @@ A general git guide can be found in the [Pro Git book](https://git-scm.com/book/
 
 ### Commit message format
 ```text
-[{task_identifier}:] commit title & summary of changes (70 char limit)
+[{jira_id}:] commit title & summary of changes (70 char limit)
 - bulleted list of specific changes
 - change two
 - change three
 ```
 
-Where `task_identifier` is the Bugzilla ID or Jira ID as appropriate.
-
 ### Examples
 ```text
 Added same-ID entity version collision resolution
@@ -79,7 +76,7 @@ Added support for the device_auth capability and status
 ```
 
 ```text
-2075587: Fixed attribute storage issue causing version collisions
+CANDLEPIN-1234: Fixed attribute storage issue causing version collisions
 
   - Fixed a bug with null-versioned product attributes causing
     version collisions due to being used in the version calculation
@@ -111,40 +108,35 @@ additional information needed to properly contextualize the changes contained in
 
 ### Pull Request Title Formatting
 #### General Format
-`[{branch_code}] {task_id}: {pr_title}`
-
-#### When both BZ and Jira are present
-`[{branch_code}] {bugzilla_id}: {pr_title} ({jira_id})`
+`[{branch_code}] {jira_id}: {pr_title}`
 
 Where:
  * **branch_code**<br/>
-   Version of the target branch (3.2, 4.0, 4.1, ‘M’ for main, or feature name for feature branches’)
- * **task_identifier**<br/>
-   The Jira or Bugzilla ID of the task associated with the change (ENT-1234, or 12345678)
+   Version of the target branch (3.2, 4.0, 4.1, ‘M’ for main, ‘F’ for feature branches’, or ‘POC’ for proof of concepts that are not supposed to be merged)
+  * **jira_id**<br/>
+   The ID of the Jira task associated with the change (e.g. CANDLEPIN-1234); should be available most of the time, except for PRs with minor changes not tracked in a jira issue
  * **pr_title**<br/>
    The title of the PR; should usually match the commit summary 1:1 unless the PR contains multiple commits,
    in which case it should be a summary of all changes
- * **bugzilla_id**<br/>
-   The ID of the Bugzilla issue associated with the change (12345678); may not be present if the change does
-   not originate from a reported issue via Bugzilla
- * **jira_id**<br/>
-   The ID of the Jira task associated with the change (ENT-1234); should always be available
 
 ### Examples
 #### Titles
- * [M] ENT-1234: Updated code to not fail when it should work
- * [4.1] 12345678: Fixed endpoint returning 500 when it shouldn’t (ENT-5678)
- * ENT-4096: Added new utility to do a thing
+ * [M] CANDLEPIN-1234: Updated code to not fail when it should work
+ * [4.6] CANDLEPIN-4096: Added new utility to do a thing
+ * [POC] CANDLEPIN-1117: Migrate to Jakarta EE
 
 #### Example PRs
- * Single-commit PR with simple change:<br/>
-   <https://github.com/candlepin/candlepin/pull/3585>
+ * Single-commit PR with simple change on the main branch:<br/>
+   <https://github.com/candlepin/candlepin/pull/5319>
 
- * Single-commit PR with a complex change:<br/>
-   <https://github.com/candlepin/candlepin/pull/3623>
+ * Single-commit PR with a complex change on the main branch:<br/>
+   <https://github.com/candlepin/candlepin/pull/5336>
 
- * Multi-commit, prototype PR:<br/>
-   <https://github.com/candlepin/candlepin/pull/3616>
+ * Single-commit PR with a complex change on a feature branch:<br/>
+   <https://github.com/candlepin/candlepin/pull/5332>
+
+ * Multi-commit, prototype/PoC PR:<br/>
+   <https://github.com/candlepin/candlepin/pull/5304>
 
 
 
@@ -213,12 +205,6 @@ The Pool's are then used to track consumption.
 ## Reading SSL Data for Debugging
 See [the debugging with wireshark page](debugging_with_wireshark.html)
 
-# Bugs
- * When marking a bugzilla as modified, include a comment with:
-   * SHA1 for the commit(s) of the branches your fix went to, be sure to do
-     this *after* you push, any rebase will change the SHA1.
-   * the version of the package the fix will appear in. (look for the most recent tag, and add 1)
-
 # Tips
 
 ## Auto-Generating candlepin.conf

docs/candlepin/jira_process.md

@@ -0,0 +1,41 @@
+---
+title: Jira process
+---
+{% include toc.md %}
+
+# Jira process
+
+ * A developer picks a [CANDLEPIN jira issue](https://issues.redhat.com/projects/CANDLEPIN/issues) that is in the `TODO` state, and:
+   * changes the state of the issue to `IN PROGRESS`.
+   * assigns it to one's self.
+   * changes the state of linked the downstream issue (SAT jira, if any) to `IN PROGRESS`.
+* All pull requests against a jira issue must have a commit message of the format "CANDLEPIN-1234: Description"
+ * Once the developer is done working and has submitted a pull request for the same, the developer changes the state of the issue to `REVIEW`
+ * Before the reviewer starts to review the pull request, the reviewer assigns the pull request to self, and adds the `Needs Second Review` label if necessary.
+ * After the pull request is merged to the target branch,
+   * the reviewer deletes the branch used for the PR.
+   * the reviewer changes the state of the jira card to `DONE`.
+   * the author of the pull request deletes the branch used for the PR if the reviewer missed it.
+ * Once the candlepin release job is done, the jira should have automatically:
+   * changed its state to `CLOSED` if it wasn't already
+   * added the candlepin RPM version to the `Fixed in Build` field
+   * changed the state of the related SAT jira (if any) to `RELEASE PENDING - UPSTREAM`.
+
+## Security process
+
+For unembargoed/public issues:
+
+1. The jira issue can be picked up and worked as usual.
+2. Email [email protected] (Red Hat Product Security), providing all relevant details and requesting a CVE identifier (if not done under embargo already). Expect a response within 48 working hours.
+3. On receiving a CVE identifier, prefix the jira issue title with the CVE identifier.
+
+For embargoed issues, handle in a similar way with these exceptions:
+
+1. Take extreme care to make no public comments, emails, pull requests or IRC conversations on the subject. Ensure anybody working on the issue follows the same.
+2. Email [email protected] (Red Hat Product Security), providing all relevant details and requesting a CVE identifier. Expect a response within 48 working hours.
+  * Use GPG-encrypted email with the key 0xDCE3823597F5EAC4 (77E7 9ABE 9367 3533 ED09 EBE2 DCE3 8235 97F5 EAC4)
+  * Mention whether or not the CVE potentially affects a Red Hat Product (RHEL or Satellite), so that ProdSec can create a respective jira against it.
+3. Decide a suitable unembargo date (often ~2 weeks) when it would also be suitable to make a release of Candlepin.
+4. Attach proposed patches to the jira issue, review in comments preferably. Don't use private comments.
+5. On unembargo, submit the patch as a pull request and/or merge if tests are green.
+6. Have the release manager of the current stable branch(es) make a patch release.