Ubuntu patches acceptance criteria
==================================

Generally, any patch is eligible for inclusion in the Ubuntu kernel, though some
criteria apply.

A patch falls into 3 categories:
 
1. It is not upstream. We call this a sauce patch. 

2. It is upstream (either mainline or stable), but part of a newer kernel version, and the submitter asks for a backport to an older Ubuntu kernel version.

3. It is part of the stable upstream for the desired kernel version, but picking it with the stable upstream patches may be delayed and there’s a request to have the specific patch as soon as possible.

!!!No matter the category, make sure you follow our guidelines before submission. Check out `Ubuntu code patches guideline`_ page. The patch should always be based on a recent kernel and expect to resubmit again if the tip changes and the patch has conflicts.

Usually, the third scenario has the biggest rate of approval if it’s done correctly. 

But the first 2 scenarios are a bit tricky and in general, we avoid merging those as much as possible.

Reasons Why the Ubuntu Kernel Team Won't Approve A Patch (Sauce or backport)
----------------------------------------------------------------------------

Note: This assumes the patch already follows our guidelines of corectness.

- **Lack of Testing**: it is very important for patches to have the upstream maintainer(s) review and do wider testing on different types of hardware for various types of scenarios. Even though the patch was tested by the submitter, the tests may be limited to a specific use case and prone to breaking other parts of the kernel affected by this change. In the case of backports, it was not tested upstream for the specific kernel version, therefore it may cause issues.

- **Maintenance**: maintaining a patch in our tree is not easy. Let’s say we include v0.54 of some patch. Later, we want to sync up to the latest version of this patch. It’s not easy to simply revert v0.54, because merges could have changed some of the code. Not to mention, there are very few patches like this that provide incremental changes between versions.

- **Core code impact**: if our kernel contains multiple sauce patches or backports, it will diverge from the upstream kernel. In case we need help from upstream to solve bugs, we will have to first test if one of these patches does not cause the bug and then ask the community for help.

- **Merge conflict**: it may cause merge conflicts later when someone from upstream changes the same piece of code. If the component is prone to frequent changes upstream, we will have to deal with this a lot and it will require extra effort on our side.

- **Security concerns**: it may open up unforeseen security issues. Not that this does not happen with upstream code, but having the code there reaches a wider audience, and more people are involved in mitigating the issue. 

- **Bug Prone**: It may introduce new bugs that have a wider impact due to limited testing, especially if the change affects a component used in many places. 

- **Quality**: not a very common reason, but the patch may not fit into our standards of code quality or may not serve any real purpose.

- **Lack of time**: maintaining these patches, with all the arguments from above, will be time-consuming on our side, and we don’t have the resources to both do this and deliver a stable Linux OS
 

.. LINKS
.. _Ubuntu code patches guideline: ./ubuntu_code_patches.html