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@xxxxxxxxxx
Commited Mar 19: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=69aaf98f41593b95c012d91b3e5adeb8360b4b8d
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.
--
Thanks,
Sasha
