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 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html