Merge pull request #5380 from jkonecny12/master-switch-makebumpver-to…

…-jira

Switch makebumpver to jira

CONTRIBUTING.rst

@@ -213,15 +213,20 @@ The first line should be a succinct description of what the commit does, startin
 Commits for RHEL Branches
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-If you are submitting a patch for any rhel-branch, the last line of your commit must identify the bugzilla bug id it fixes, using the ``Resolves`` or ``Related`` keyword, e.g.:
-``Resolves: rhbz#111111``
+If you are submitting a patch for any rhel-branch, the last line of your commit must identify the `JIRA issue <https://issues.redhat.com/projects/RHEL/issues/>`_ id it fixes, using the ``Resolves``, ``Related`` or ``Reverts`` keyword, e.g.:
+``Resolves: RHEL-11111``
 
 or
 
-``Related: rhbz#1234567``
+``Related: RHEL-12345``
+
+or
+
+``Reverts: RHEL-22222``
 
 Use ``Resolves`` if the patch fixes the core issue which caused the bug.
 Use ``Related`` if the patch fixes an ancillary issue that is related to, but might not actually fix the bug.
+Use ``Reverts`` if this patch reverts changes introduced by linked bug.
 
 Release Notes
 ^^^^^^^^^^^^^

docs/commit-log.rst

@@ -5,24 +5,15 @@ git commit messages for anaconda should follow a consistent format.  The
 following are rules to follow when committing a change to the git repo:
 
 1) The first line of the commit message should be a short summary of the
-   change in the patch. If the alterations pertain to a specific UI deliverable
-   in Anaconda, begin the line with the lowercase name - gui, tui. We
-   also place (#BUGNUMBER) at the end of this line to indicate the
-   bugzilla.redhat.com bug number addressed in this patch. The bug number is
-   optional since there may be no bug number, but if you have one you are
-   addressing, please include it on the summary line. Lastly, the summary lines
-   need to be short. Ideally less than 75 characters, but certainly not longer
-   than 80.
+   change in the patch. Ideally less than 75 characters, but certainly not
+   longer than 80. If the alterations pertain to a specific UI deliverable
+   in Anaconda, begin the line with the lowercase name - gui, tui.
 
    Here are acceptable first lines for git commit messages::
 
-       Check partition and filesystem type on upgrade (#123456)
-       Fix bootloader configuration setup on ppc64 (#987654)
+       Fix bootloader configuration setup on ppc64
        gui: Introduce a new screen for setting your preferred email client
 
-   The last one would be a new feature that we didn't have a bug number
-   for.
-
 2) The main body of the commit message should begin TWO LINES below the
    summary line you just entered (that is, there needs to be a blank line
    between the one line summary and the start of the long commit message).
@@ -32,32 +23,25 @@ following are rules to follow when committing a change to the git repo:
    wrap long lines.  If you don't, the 'git log' output ends up looking
    stupid on 80 column terminals.
 
-3) For RHEL bugs, all commits need to reference a bug number.  You may
-   follow one of two formats for specifying the bug number in a RHEL commit.
-
-   a)  Put the bug number on the summary line in (#BUGNUMBER) format.  Bugs
-       listed this way are treated as 'Resolves' patches in the RHEL
-       universe.
-
-   b)  If you have a patch that is Related to or Conflicts with another bug,
-       you may add those lines to the end of the long commit message in this
-       format::
+3) For RHEL or CentOS Stream bugs, all commits need to reference a bug
+   issue name. These bugs can be filed
+   `here <https://issues.redhat.com/projects/RHEL/issues>`_.
 
-           Related: rhbz#BUGNUMBER
-           Conflicts: rhbz#BUGNUMBER
-           Resolves: rhbz#BUGNUMBER
+   If you have a patch that is Related to or Reverts another bug,
+   you may add those line to the end of the long commit message in this
+   format::
 
-       These entries should come at the end of the long commit message and
-       must follow the format above.  You may have as many of these lines as
-       appropriate for the patch.
+       Related: RHEL-ISSUENUMBER
+       Reverts: RHEL-ISSUENUMBER
+       Resolves: RHEL-ISSUENUMBER
 
-   c)  Patches that are 'Resolves' patches have two methods to specify the
-       bug numbers, but Related and Conflicts can only be listed in the long
-       commit message.
+   These entries should come at the end of the long commit message and
+   must follow the format above.  You may have as many of these lines as
+   appropriate for the patch.
 
    On RHEL branches, the 'bumpver' process will verify that each patch for
-   the release references a RHEL bug number.  The scripts/makebumpver script
-   will extract the bug numbers from RHEL branch commits and do two things.
+   the release references a RHEL issue.  The scripts/makebumpver script
+   will extract the bug issues from RHEL branch commits and do two things.
    First, it verifies that the bug referenced is a RHEL bug and in correct
-   states.  Second, it adds the appropriate Resolves/Related/Conflicts line
+   states.  Second, it adds the appropriate Resolves/Related/Reverts line
    to the RPM spec file changelog.