Frequently Asked Questions

The most common questions related to contributing to Red Hat-based kernel projects.

1.1. I submitted an MR but it was rejected for 'non-technical' issues. Why did that happen and what does it mean?

CentOS Stream, and by extension Red Hat, welcome all community requests and contributions to the CentOS Stream kernel. Red Hat applies Development, QE, Documentation, and other resources to every change made to the CentOS Stream kernel to ensure the CentOS Stream and RHEL kernels are secure, highly available, and meet Red Hat’s users’ requirements. The maintainers may reject a change because they are aware of a lack of resources available to provide support for the change. For example, a community user or SIG may request that a particular driver be enabled and Red Hat may not have access to hardware associated with the driver. In this case, CentOS Stream and Red Hat cannot provide any guarantee on functionality to users, and as such the request would be rejected. Please take a moment to understand: We do not like to reject contributions and consider any rejections to be a loss for the overall community behind CentOS Stream and RHEL, but unfortunately, we are also resource constrained.

1.2. I can support the hardware or software that was rejected for 'non-technical' issues. Isn’t that enough?

Unfortunately, no. While we appreciate your enthusiasm and help, Red Hat has support requirements it must meet and a lack of ability to reproduce a problem will cause a delay in support for users and customers.

1.3. Are there any other options to getting my changes into the Centos Stream kernel?

Yes! You can consider forming a Centos Stream SIG for your changes, or joining a similarly aligned existing SIG.

2.1. The formatting is bad, how do I fix it?

Descriptions and comments utilize GitLab Flavored Markdown to handle the formatting of the text.
Consecutive lines separated by single newlines, without a blank line in between, will be treated as a paragraph for purposes of display. The MR tools will still see the newlines and will treat such labeled fields (“JIRA:”, etc) as intended. If you want a cleaner display, insert a blank line between entries.
Indented blocks of text get a box around them, which can cause unintended consequences on the formatting of the display of your description..

3.1. I have a red `Unmet Requirement` label , what does this mean and how do I fix it?

Review the listed Dependencies in the MR Summary.
Find each of the MR associated with the Dependencies line(s)
Compare the common commits between this MR and each of the dependent MR commits.
1. If any of the common commits have different ID’s, the Dependency check will be marked as RED.
2. To resolve, this MR must be rebased upon the tree containing the mismatched commit ID. === I opened a new MR, but there is a Label. What is the problem? :sectnums:
First, confirm whether you can see a Pipelines tab on the MR itself.
1. Try to REMOVE the label. This will trigger the system to re-run the webhook and will likely return as if the test ran OK but the webhook hasn’t posted the update yet.
2. If the label returns, go into the Pipelines tab and press the button. That will generate some results that should satisfy the unmet requirement.
If the Pipelines tab is missing:
1. A possible cause is that the source branch (on your fork) is named main. The name main is protected and is not able to trigger a pipeline job. To resolve this, close the current MR, rename the branch on your fork and open a new MR.
2. Another possible cause is that you have insufficient permissions. Find another associate in your organization that can look to confirm whether they see the missing tab (and button on that tab)
  1. If they can see it, ask them to click the button and then refer to My MR is behaving weirdly, I’m not sure what to do…

3.2. What does indicate?

This is currently only an informational alert. It does not have an impact on the ability of an MR to be merged.
1. This is intended to transition to a blocking tag in the future, but there are no timelines attached to this effort currently.
It is currently consumed by QA teams that are working on identifying testing gaps. The label indicates that the changed code in this commit did not have any specific tests that target the affected area. Baseline testing (booting, functional, standard regression, etc.) is still performed and validated.

3.3. What does indicate?

This label indicates that the Merge Request must pass a CI that is not part of the usual Continuous Kernel Integration (CKI). Such external CIs are managed by individual subsystems. Look for other ExternalCI labels (such as ; see below) to find out what subsystem or subsystems mandated the testing.

3.4. What does indicate?

This label indicates that the Merge Request modifies kernel networking and requires network specific testing by the LNST test suite. Usually, you don’t have to do anything. Your merge request will be automatically picked up and tested. If the tests pass, the label will be changed to .
If your merge request previously modified kernel networking by mistake and you later changed that and force pushed the MR, the label will not be automatically removed. In such case, you can remove the label yourself. It is safe to attempt the removal; if the MR still modifies the kernel networking, the label will be restored. Note that kernel networking is not limited to .
If your merge request is critical and you need to expedite the testing, contact the Networking Team kernel maintainers at kernel-net-submaint@redhat.com.

4. MR Interactions

4.1. How do I make the webhook re-evaluate the readiness of a MR?

Remove the label you want re-checked by clicking the 'x' in the Labels area as defined above under step 8. (i.e. if you have , remove that label from the MR)

4.2. The link I received to create the MR for my change only refers to my fork and not the upstream kernel tree. Why did this happen and how do I resolve it?

This typically happens if you have inadvertently cloned your fork and the origin remote points at your fork rather than the upstream tree.
It is recommended that you clone the upstream tree, not your fork.
If that is not an option, then you can specify the remote to use when creating the MR.
(reported on kernel-info.)

4.3. I followed the commit rules as detailed, why do I have a red label that is seemingly satisfied?

Things to be aware of: … Even extra leading whitespace can cause problems, and may not be obvious in some browsers. …. https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/141 shows an example where fields were indented but not rendered as such. … Beware that some formatting is masked by the web interface that can only be seen via the edit interface. (for example, the <>'s around an email address in the DCO sign-off) …. https://gitlab.com/redhat/rhel/src/kernel/rhel-8/-/merge_requests/1720 shows an example of this.

4.4. My MR is behaving weirdly, I’m not sure what to do…

First and foremost, make sure to click the GitLabSSO link to refresh your permissions.
Reach out to your KWF Representative for assistance.
Send an email to kernel-info@redhat.com.
If there’s a GitLab specific issue, you can open an issue at Red Hat Kernel bug reports.

The jira webhook will post a comment to the MR with the current status of each referenced ticket. Each time the webhook is run, that comment will be edited to reflect the current state.

4.6. Can I edit my comments?

Minor modifications to an existing MR comment are allowed.
A minor modiviation can be defined mostly as correcting a typo or adjusting the language of a sentence that is otherwise unclear (i.e. perhaps there’s a word missing).
It is important to keep comments as close to their original intent as possible since they are used for auditing purposes.

4.7. How do I get build artifacts without looking at Jira?

Search by Merge Request ID.
Navigate to the CKI Datawarehouse tab and search for the Merge Request ID.

It is possible to search by a pipeline ID.

Find the pipelines tab and click it
Find the most recent build and click the pipeline number

4.8. When I attempt to click the new Merge Request link after a push, I get an error. How do I resolve it?

Occasionally, when clicking the link that is provided after a git push, the browser page that opens returns an HTTP 500 error.

   500
   Whoops, something went wrong on our end.
   Request ID: 01GQ0QHBS01AZNMPGYFC0JBEG9

   Try refreshing the page, or going back and attempting the action again.

   Please contact your GitLab administrator if this problem persists.

This is caused by an issue on the GitLab server side. Try the following steps to resolve or work around the problem:

Retry after a few minutes. (Try this step a couple of times before moving on)
1. Sometimes it can just be a transient problem and waiting 5-10 minutes may be enough to fix the problem.
Consider opening a support ticket with GitLab.
Work around the problem by using the lab utility or gitlab-cli.

4.9. Why is GitLab asking for credit card information in my MR?

Pipelines are trying to run in your personal namespace. This can have various reasons:

You have submitted a merge request against your own fork instead of the gitlab.com/redhat namespace. You can resolve this by resubmitting the merge request against the correct target project.
You have used a source branch name that is protected in the target project, for example, 'main'. You can resolve this by resubmitting your merge request from a source branch that does not match any of the protected branches of the target project.