Bugzilla Lifecycle

As with every process, it must begin somewhere. For Bugzilla and the Kernel Workflow process, this status ends up being NEW. This indicates that the BZ is just that, new. It has not been reviewed, triaged, or considered for fixing or addressing yet.

BZ’s that are in this state will be periodically reviewed by their current default assignee, which is determined by the component and sub-component that was chosen. A BZ may be transferred between multiple components and sub-components until the appropriate destination has been determined.

Every team has their own review process, but common to them all is that once a BZ has been triaged, it will then be moved to ASSIGNED to an individual to review and evaluate the BZ. As part of the triage process, a BZ can also just move directly to the CLOSED status if it is not appropriate to keep open. Reasons could be that the BZ has already been addressed (and therefore would be CLOSED → DUPLICATE) or maybe it’s something else (e.g. user error).

Once a BZ has been triaged and ASSIGNED to an individual, they will review the details of it and identify what needs to be done. Assuming a change is required, the BZ will then be scheduled for a particular release, which requires setting a number of internal-only visible fields such as Development Target Milestone, Internal Target Milestone, and Internal Target Release.

In the most basic scenario (before ITM 26, and not for a Z-Stream), a BZ is approved once the release+ flag is granted. For more information, visit the Get Release Approval section in the Quick Start Guide.

Once a change has been prepared for the kernel, it needs to be made available for review. To indicate that the update is ready to be looked at, the state of the BZ should be changed to POST. Almost along the lines of it being POST-ed to a bulletin board for people to see. This step will be automatically completed by the webhooks once the BZ has been detected in the description.

For the RHEL Kernel Workflow process, the update is provided via the GitLab Merge Request interface.

All changes to the RHEL kernel are done via the GitLab Merge Request interface. For more detailed information about this process, please visit the Quick Start Guide. As soon as the web hooks in the GitLab infrastructure notices a referenced BZ in the description, a link will be added to the BZ pointing at the relevant Merge Request(s).

The loose process, however, looks like this:

Once the Merge Request has received sufficient reviews and the CKI test has passed, the readyForQA label will be applied to it. It is at this point that the BZ status will be moved from POST to MODIFIED. The assigned QE engineer will verify that the change does what was intended. This is typically done by using the reproduction steps that were noted in the BZ’s description field when it was originally opened. From there, the QE Engineer will set the Verified Field to Tested.

After the BZ’s Verified field is updated to Tested (or equivalent), the Merge Request should now have the readyForMerge label applied to it. This is the signal to the Kernel Maintainer that the merge request is ready to be pulled into a delivery candidate kernel build. When the update does get pulled in, the affected BZ statuses will be updated to MODIFIED.

The maintainers assemble a new kernel periodically to deliver the various updates that they were provided. The schedule on this can vary, but when times are busy enough it’s not uncommon to see a new kernel at least once per week. As part of this process, the kernel undergoes its own set of CKI tests just like every other Merge Request. Once the new kernel has gotten past the gating phase, it is tagged in the infrastructure to be used in the next upcoming composes. It is at this point that the BZ will transition from MODIFIED to ON_QA by adding it to an existing errata advisory.

Just like in previous steps, when the BZ reaches the ON_QA status, it is a signal to QE that they can perform final verification of the BZ based on the description steps that were provided.A If everything checks out, the QE engineer will mark the BZ as VERIFIED. The BZ will remain in this state until it is released with an update for RHEL.

During the release process, all BZ’s attached to the relevant errata advisories for a particular RHEL release will be closed. The BZ status is then updated to CLOSED and resolution CURRENT_RELEASE. It is at this point that the involvement of the BZ has concluded its responsibilities in relation to RHEL, the RHEL Kernel, and the issues that it addresses.