Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Linux kernel development moves in a rolling cycle: a roughly two-week merge window admits larger changes, then -rc1 starts stabilization for the next mainline release. More candidates usually appear about weekly until regressions and other bugs are judged under control. Patch review happens on subsystem mailing lists and maintainer trees, while linux-next combines that work for integration testing. Stable candidates follow a separate, narrower process for fixes to an already released kernel.
The kernel release cycle in one view
Linux does not use a fixed, calendar-driven release schedule. The process is loosely time-based: maintainers and developers use typical intervals as guidance, but the final release depends on the condition of the code. The official process description says a normal cycle has a merge window of approximately two weeks, followed by a stabilization period that commonly lasts six to ten weeks. These are approximate descriptions in the rolling kernel documentation, not promises for every version.
| Stage | What changes are expected | Typical timing or result |
|---|---|---|
| Previous mainline release | The next cycle starts after the current kernel is released. | Development work is prepared in subsystem trees. |
| Merge window | Larger, sufficiently mature features and changes can be merged. | About two weeks. |
-rc1 |
The merge window closes; the emphasis changes from new features to stabilization. | First release candidate for the next mainline version. |
Later -rc releases |
Fixes for regressions and other bugs are evaluated and tested. | Usually about one week apart; many cycles reach -rc6 through -rc9. |
| Final release | The maintainer judges the tree ready enough to publish. | No guaranteed date; perceived bug status is decisive. |
What “-rc” means
“RC” means release candidate. A mainline candidate is a testable snapshot of the next development release, not a promise that the code is finished or suitable for every production machine. The suffix identifies its position in the stabilization sequence: 6.10-rc1, for example, would be the first candidate after the 6.10 merge window.
-rc1 has a specific process meaning. It marks the point at which the normal opportunity for introducing new features has ended. After that point, the general rule is to submit fixes rather than expand the feature set. A serious regression—especially behavior that worked in an earlier kernel and now fails—receives particular attention.
#1 Best Overall
Subsequent candidates are commonly published around once a week when the tree is ready for another round of testing. A cycle often reaches somewhere between -rc6 and -rc9, but that range is not a release contract. If important regressions remain, more candidates can be issued; if the code is judged ready sooner, the final release can arrive earlier. The process documentation quotes kernel developer Andrew Morton: “Nobody knows when a kernel will be released, because it’s released according to perceived bug status, not according to a preconceived timeline.” You can read the explanation in the kernel development-process documentation.
Why a known regression can delay a release
Maintainers try to fix regressions before declaring a final release because a change that breaks previously working behavior can affect users more severely than an isolated new bug. Nevertheless, the documentation acknowledges that a final kernel can still have known regressions when delaying it would make the next development cycle worse. “Ready” therefore means an engineering judgment about risk and progress, not proof that every defect has disappeared.
A historical example, not a forecast
The process guide uses Linux 5.4 to illustrate the cadence: 5.4-rc1 was released on September 30, 2019, and the final 5.4 kernel followed on November 24, 2019. Those dates show how a cycle can unfold, but they do not predict the timing of a current or future kernel.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How a patch travels toward mainline
A patch normally moves through a subsystem community rather than being sent directly to a single central reviewer. The path can include design discussion, early review, wider review, subsystem acceptance, integration testing, mainline merging, and later maintenance. Not every patch follows every step in exactly the same way, and acceptance by a subsystem maintainer is not a guarantee that Linus Torvalds will eventually merge it.
1. Explain the problem and proposed change
Start by identifying the user-visible or developer-visible problem. A useful submission says what fails, who is affected, under which conditions it fails, and what the patch changes. Explain trade-offs as well as benefits; a faster path that consumes more memory, for example, needs that cost documented rather than hidden.
2. Find the correct subsystem
The kernel’s MAINTAINERS file identifies the people, mailing list, and tree associated with a subsystem. Read the relevant entry and then check that subsystem’s own workflow rules. Review conventions differ: some communities require particular subject prefixes, test procedures, or prerequisite patches. The official patch-submission guide explains the general expectations, but subsystem instructions take precedence for local details.
3. Send the patch for mailing-list review
Kernel review is primarily conducted in public mailing-list threads. Reviewers examine the design, code, interfaces, error handling, documentation, and tests. A submission should include relevant evidence—such as reproduction conditions, logs, crash information, or quantified performance results when those measurements matter. Keep one patch, or a logically ordered patch series, focused on one problem so reviewers can reason about its effect.
4. Respond and resend a complete series
Review commonly produces requested changes. Each resubmission should be self-contained: include the full description and justification again rather than assuming a future reader can reconstruct them from an older thread. Explain what changed since the previous version and address review concerns directly. Some subsystems also use Patchwork to track patch state and discussion, as described in the kernel’s submission guidance.
5. Enter the subsystem tree
A subsystem maintainer may accept the patch into a development tree. That tree allows more review and exposes interactions with other work. It is an important milestone, but it is not a promise of mainline inclusion: maintainers can drop, revise, or defer a patch if testing reveals a problem or priorities change.
Where linux-next fits
linux-next is an integration-testing repository. It pulls work from multiple subsystem trees so developers can see how changes interact before a future merge window. A patch that works in isolation can conflict with another subsystem, expose an API mismatch, or trigger a regression only when both branches are present; integrating them early makes those failures visible while there is still time to fix them.
The official HOWTO invites adventurous testers to runtime-test linux-next. It is a useful target when you want to find integration problems rather than merely verify one isolated patch. Because it contains in-progress work, it carries more risk than a normal stable kernel. Test it on hardware and workloads where failure is acceptable, keep a known-good kernel available, and report exact configurations and reproducing steps to the relevant community.
Free tools Windows power users keep installed
One-click scans. No signup required.
A mainline release candidate serves a different but related purpose. It represents the combined tree after the merge window and is intended to expose regressions in the release being stabilized. Testing both linux-next and mainline -rc kernels can provide earlier evidence, but neither has been tested for every device, driver, workload, or distribution configuration.
Rank #4
How to test a release candidate responsibly
- Choose the right target. Use
linux-nextwhen you are intentionally testing upcoming subsystem integration; use a mainline-rcwhen checking the next release’s broader stabilization; use a stable candidate when validating a proposed maintenance update. - Keep recovery available. Retain a known-working kernel in the bootloader and ensure you can recover your filesystem, networking, and remote-access path if the candidate fails.
- Record the environment. Note the exact kernel identifier, architecture, hardware, firmware, distribution configuration, workload, and any out-of-tree modules. Without this context, a report is difficult to reproduce.
- Exercise the affected path. Reproduce the original bug or run the workload that matters to you. Include logs, crash information, and performance measurements when they distinguish the candidate from the previous kernel.
- Report both failures and useful confirmation. A clear regression report should say what worked before, what changed, how to reproduce the failure, and whether the problem occurs consistently. Successful testing is also valuable when the patch author requests confirmation.
Testing is evidence, not a blanket guarantee. A candidate that passes your workload may still fail on another controller, filesystem, CPU, or power-management configuration. Conversely, a failure in an unusual environment can reveal a real regression that maintainers need to understand.
Mainline candidates versus stable candidates
| Question | Mainline -rc |
Stable -rc |
|---|---|---|
| Purpose | Stabilize the next major development release after its merge window. | Test a proposed set of fixes for an already released stable series. |
| Scope | Broad combined changes, with new features normally frozen after -rc1. |
Selected fixes; it is not a channel for general new features. |
| Risk profile | Development testing across a changing, newly integrated kernel. | Maintenance testing focused on whether queued fixes are safe for that stable line. |
| How feedback is given | Mailing-list reports, regression reports, logs, and workload results. | A tester can reply with a Tested-by: tag describing the test; the tag may be collected into the eventual release commit. |
| What a pass means | Your tested configuration behaved as expected; it does not certify all systems. | Your tested configuration supports the proposed update; it does not certify every stable user. |
The stable-kernel rules say a stable fix, or an equivalent change, should already exist in mainline and should address a significant real problem. Stable patches have their own review and testing cycle. The review committee can issue ACK or NAK feedback, and additional candidates can be published if problems remain. Security issues have a distinct handling process in the official guidance, so they should not be treated as ordinary stable backports.
What reviewers need from a strong submission
- A precise problem statement: describe the failure in plain language and identify the affected users or systems.
- Reproduction information: provide the conditions, steps, configuration, and frequency needed to reproduce the issue.
- Evidence: attach relevant logs or crash data; include measured performance results when performance is part of the claim.
- Reasoning: explain why the proposed design is appropriate and disclose costs or trade-offs.
- Narrow scope: avoid bundling unrelated cleanup or features with a bug fix.
- Complete revisions: resend the full description and justification with each version, while noting what changed since the prior review.
- Correct routing: address the subsystem maintainers and mailing list identified by
MAINTAINERS, and follow any subsystem-specific process.
These practices make review faster because a maintainer can evaluate the actual impact instead of guessing at the motivation or reproducing an undocumented environment.
Why “accepted” does not always mean “merged”
Subsystem trees are staging and integration points. A maintainer can accept a patch for additional testing, yet later drop it because it conflicts with another branch, causes a regression, lacks a required review, or no longer solves the current problem. Work in a subsystem tree must still survive integration in linux-next, the merge window, and the mainline maintainer’s final decisions. Treat each stage as evidence of progress, not as a guarantee.
Best Value
Choosing a kernel for ordinary use
For a production system, the distinction between development testing and maintenance testing matters more than the “latest” label. A mainline -rc is appropriate when you are able to diagnose regressions and contribute reports, or when you specifically need to test an upcoming change. A stable release is the more conservative choice for ordinary workloads that cannot tolerate development risk. A stable -rc can be useful when you want to validate a proposed fix before it reaches the stable release, but it is still a candidate and should be treated as such.
Do not interpret either candidate label as evidence that the kernel has been tested on your particular hardware. The meaningful question is whether your own configuration and workload have been exercised, whether a recovery path exists, and whether failures can be reported with enough detail for developers to act.
Key takeaways
-rc1follows the approximately two-week merge window and starts stabilization; new features are normally no longer accepted after that point.- Later candidates are usually about a week apart, with many cycles reaching
-rc6to-rc9, but bug status—not a fixed date—determines the final release. - Patch review begins with the relevant community and mailing list, then proceeds through subsystem maintainers and trees; subsystem acceptance is not a final-merge guarantee.
linux-nextcombines subsystem work for integration testing before a future merge window and is intended for experienced or adventurous testers.- Stable candidates test selected fixes for an existing stable series through a separate review path; they are not a general feature-development channel.
The official process descriptions are maintained in the Linux kernel development HOWTO, the development-process guide, the patch-submission guide, and the stable-kernel rules. Their timing guidance is approximate and should be checked again when a particular release or maintainer workflow matters.
Recommended Free Tools
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
