From: Li Zefan <lizefan@huawei.com>
To: Jack Wang <jinpu.wang@profitbricks.com>
Cc: stable <stable@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Sebastian Riemer <sebastian.riemer@profitbricks.com>
Subject: Re: [STABLE] find missing bug fixes in a stable kernel
Date: Tue, 14 Jan 2014 09:45:53 +0800 [thread overview]
Message-ID: <52D496D1.2080104@huawei.com> (raw)
In-Reply-To: <52D3B411.70106@profitbricks.com>
On 2014/1/13 17:38, Jack Wang wrote:
> On 01/13/2014 08:28 AM, 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
> Hello Zefan,
>
> Thanks for share, great job, it's very useful info for other companies
> who build their kernel base on long term kernel like here in ProfitBricks.
>
This can also be used to find bug fixes for 2.6.34 stable. As 2.6.34.xx isn't
maintained anymore while 2.6.32.xx is still being taken care of.
> I'm a little confused about the column occurrences, what do the 2
> numbers mean, eg :
> 8c4f3c3fa968 874d3954a35c 2 1
> the first is the occurrences in upstream and second for the occurrence
> in 3.2.xx right?
>
Yeah. As I replied to Greg, you can think of this as
# git log v3.2..v3.2.61 | grep -c 8c4f3c3fa968
# git log v3.2..v3.2.61 | grep -c 874d3954a35c
next prev parent reply other threads:[~2014-01-14 1:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-13 7:28 [STABLE] find missing bug fixes in a stable kernel Li Zefan
2014-01-13 9:38 ` Jack Wang
2014-01-14 1:45 ` Li Zefan [this message]
2014-01-13 15:57 ` Greg Kroah-Hartman
2014-01-14 1:37 ` Li Zefan
2014-01-15 4:06 ` Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D496D1.2080104@huawei.com \
--to=lizefan@huawei.com \
--cc=gregkh@linuxfoundation.org \
--cc=jinpu.wang@profitbricks.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sebastian.riemer@profitbricks.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).