On Mon, Jan 13, 2014 at 03:28:11PM +0800, Li Zefan wrote:

We have several long-term and extended stable kernels, and it's possible
that a bug fix is in some stable versions but is missing in some other
versions, so I've written a script to find out those fixes.

Take 3.4.xx and 3.2.xx for example. If a bug fix was merged into upstream
kernel after 3.4, and then it was backported to 3.2.xx, then it probably
needs to be backported to 3.4.xx.

I agree.

The result is, there're ~430 bug fixes in 3.2.xx that probably need to be
backported to 3.4.xx. Given there're about 4500 commits in 3.2.xx, that
is ~10%, which is quite a big number for stable kernels.

That's a really big number, how am I missing so many patches for the 3.4
kernel?  Is it because people are doing backports to 3.2 for patches
that didn't apply to 3.4?  Or are these patches being applied that do
not have -stable markings on them?  Or something else?

We (our team in Huawei) are going to go through the whole list to filter
out fixes that're applicable for 3.4.xx.

I've attached the lists for 3.4 and 3.10.

The list format doesn't seem to make much sense, care to explain it a
bit better?

If a commit ID appears more than once in changelogs, it's possible that's
because the commit was reverted later, so I tagged this kind of commits
in the lists.

[upstream commit]    [stable commit]    [occurrences]
8c4f3c3fa968 874d3954a35c 2 1

I'll use this as an example, this patch was not marked for -stable
backporting, yet it showed up in the 3.2-stable tree.  Why?

And what does the [occurrences] column mean?

confused,

greg k-h