On Thu, Mar 30, 2023 at 12:08:01AM +0000, Eric Biggers wrote:
Hi Sasha,
On Mon, Feb 27, 2023 at 07:52:39PM -0500, Sasha Levin wrote:
Sasha, 7 days is too short. People have to be allowed to take holiday.
That's true, and I don't have strong objections to making it longer. How often did it happen though? We don't end up getting too many replies past the 7 day window.
I'll bump it to 14 days for a few months and see if it changes anything.
I see that for recent AUTOSEL patches you're still using 7 days. In fact, it seems you may have even decreased it further to 5 days:
Sent Mar 14: https://lore.kernel.org/stable/20230314124435.471553-2-sashal@kernel.org Commited Mar 19: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/comm...
Any update on your plan to increase it to 14 days?
The commit you've pointed to was merged into Linus's tree on Feb 28th, and the first LTS tree that it was released in went out on March 22nd.
Quoting the concern you've raised around the process:
BTW, another cause of this is that the commit (66f99628eb24) was AUTOSEL'd after only being in mainline for 4 days, and *released* in all LTS kernels after only being in mainline for 12 days. Surely that's a timeline befitting a critical security vulnerability, not some random neural-network-selected commit that wasn't even fixing anything?
So now there's at least 14 days between mainline inclusion and a release in an LTS kernel, does that not conform with what you thought I'd be doing?
Most of that additional time comes in the form of me going over the tree and sending AUTOSEL mails a bit later, so I would be able to also pick follow-up fixes as they come in (and drop stuff that were reverted).
As a side note, inclusion into the stable-queue which you've pointed to above is a few steps before a release - it's mostly a cheap way for us to get mileage out of bots that run on the queue and address issues - it doesn't mean that the commit is released.