| Blacklisting Upstream Commit-IDs |
| ================================ |
| |
| We track the git history of the upstream Linux kernel for fixes that we |
| potentially need to backport to our kernel branches. The tooling creates |
| a list of upstream commit-ids that are already part of our kernels and |
| compares the 'Fixes:' tags in upstream commits with that list. If there |
| is a match, we found a fix that might need to be backported. |
| |
| If the commit is not needed in our kernels, it can be blacklisted, so |
| that the tools do not report that commit again. There are two ways to |
| blacklist a commit: |
| |
| 1) Put the commit-id into blacklist.conf. This file exists to |
| blacklist fixes for the base kernel version of the branch. |
| |
| 2) Use the 'No-Fix:' tag in the patch-files. The format of that |
| tag is the same as for the 'Git-commit:' tag. Only one commit |
| can be blacklisted per tag, you have to use 'No-Fix:' once |
| for each commit to be blacklisted. This option can be used to |
| blacklist fixes for an already backported upstream patch. |
| |
| Both options require a full 40-character git commit-id. |
| |
| The blacklist.conf file also supports blacklisting by source code path. |
| A list of paths can be put into that file and patches that only touch |
| these paths are automatically blacklisted too. |
| |
| Feel free to send any questions and/or suggestions about fixes-tracking |
| and blacklisting to: |
| |
| |
| Joerg Roedel <jroedel@suse.de> |
| |