Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <24edd13e-791a-bd05-0a44-dd5475c7e200@leemhuis.info>
Date:   Sun, 18 Jun 2023 15:40:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Content-Language: en-US, de-DE
From:   Thorsten Leemhuis <linux@leemhuis.info>
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        Greg KH <gregkh@linuxfoundation.org>
Cc:     Linux kernel regressions list <regressions@lists.linux.dev>,
        LKML <linux-kernel@vger.kernel.org>
References: <9e0f5378-63d8-add4-2b79-2173a4c98086@leemhuis.info>
Subject: Re: JFYI: patches in next that might be good to mainline rather
 sooner than later?
In-Reply-To: <9e0f5378-63d8-add4-2b79-2173a4c98086@leemhuis.info>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 18.06.23 10:49, Thorsten Leemhuis wrote:
> Hi Linus, hi Greg,
> 
> I got the impression that early stable releases with a huge number of
> patches (like 6.3.2 with ~690 changes) seems to cause a few regressions.
> As you know, those releases usually contain many backports of changes
> merged during the merge window for the following mainline release (e.g.
> 6.4). That made me wonder:
> 
> How many patches do we have in linux-next right now that better should
> be merged this cycle (e.g. ahead of the 6.4 release) instead of merging
> them in the merge window for 6.5 and backporting them shortly afterwards?
> 
> To check I briefly set down and quickly hacked together a python
> script[1] that looks at linux-next for patches with tags like 'Cc:
> stable...' and 'Fixes: ', as all respectively some (or many?) of those
> will be backported. I made the script ignore a few things, like commits
> from the past eight days and commits that fix changes committed to
> mainline more that a year ago.
> 
> I ran this a few minutes ago and it spilled out about 260 changes (about
> 80 of them with a stable tag). I put the results into a table:
> https://docs.google.com/spreadsheets/d/1OnMrde1e7LBMPhOPJL0Sn9rd3W32mTGls_qGMoZS8z8/edit?usp=sharing

TWIMC, I just updated the data slightly, as I updated the script to also
look for commits that revert changes from the current mainline cycle.

Did that while I was preparing this weeks regression report and noticed
a series of reverts[1] in next where my brain said "hmmm, Andrew merged
those more than a week ago to mm-hotfixes-unstable and -rc7 is due
today; I don't see a pr from him and wonder if these revert are
something that better should be in rc7 to help preventing a rc8?"

[1] https://lore.kernel.org/all/20230609081518.3039120-1-qi.zheng@linux.dev/
noticed it via
https://lore.kernel.org/lkml/ZH6K0McWBeCjaf16@dread.disaster.area/

BTW, quick reminder for the data in the spreadsheet, to ensure nobody
gets this wrong:

> [...] And I'm not suggesting to merge them [to mainline].
> It was just a exercise to see if this might be useful.

IOW: the spreadsheet definitely mentioned commits in next that
definitely are not suited for this merge window.

Ciao, Thorsten