Chasing patches into Linux

One thing that often seems to cause problems for people who work over many different areas of the Linux kernel is the process of making sure that patches actually get reviewed and applied. Where the relevant subsystem is actively maintained it’s not a problem but that’s not always the case. Sometimes maintainers are busy or on holiday and miss things, sometimes there are other problems. In these cases the onus is on the patch submitter to spot the problem and make sure that something is done to ensure that the patch doesn’t get forgotten.

There’s a few  workflows for dealing with this. My preferred one is to track the appearance of my patches in Stephen Rothwell’s linux-next tree, which tracks individual development trees destined for merge into Linus’ tree. I create a git branch based on the current state of this tree then apply the patches I’m submitting on top of that. This lets me spot any potential merge conflicts that they’ll create but the main function is to allow me to come back to the branch later and track which of the patches has shown up in one of the trees that Stephen tracks. To do this I rebase the branch onto the current state of linux-next:

git rebase --onto next/master old-master

where ‘old-master’ is the last linux-next commit in the branch. This will flag up any merge issues that have come up due to changes in other trees and will also handle patches that are already present in one of the trees in -next by dropping my local version. The end result is a branch based on the new linux-next with all the patches that were not yet applied in it. I can see what still needs to be looked at by examining the log

git shortlog next/master..

and take any appropriate action, such as following up with the relevant maintainer or trying to find out what’s going on with the subsytem if it looks like the subsystem maintainers are inactive.

One possible problem with this approach is that a patch may be applied and then subsequently dropped – this is rare but it can happen. I deal with that by also keeping a normal unrebased development branch whch has the changes in Linus’ tree merged  into it periodically and incremental patches for any review updates that occur during the submission process. By looking at the diff between that and other trees I can see any changes that have got lost along the way.