On Thu, Mar 30, 2023 at 10:22:10AM -0700, Eric Biggers wrote:
On Thu, Mar 30, 2023 at 10:05:39AM -0400, Sasha Levin wrote:
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?
Not quite. There are actually two different time periods:
1. The time from mainline to release
2. The time from AUTOSEL email to release
(1) is a superset of (2), but concerns were raised about *both* time periods
being too short. Especially (1), but also (2) because reviewers can miss the
7-day review e.g. if they are on vacation for a week. Yes, they can of course
miss non-AUTOSEL patches too, *if* they happen to get merged quickly enough
(most kernel patches take several weeks just to get to mainline). But, AUTOSEL
patches are known to be low quality submissions that really need that review.
I'm glad to hear that you've increased (1) to 14 days! However, that does not
address (2). It also does not feel like much of a difference, since 12 days for
(1) already seemed too short.
To be honest, I hesitate a bit to give you a precise suggestion, as it's liable
to be used to push back on future suggestions as "this is what people agreed on
before". (Just as you did in this thread, with saying 7 days had been agreed on
before.) And it's not like there are any magic numbers -- we just know that the
current periods seem to be too short. But, for a simple change, I think
increasing (2) to 14 days would be reasonable, as that automatically gives 14
days for (1) too. If it isn't too much trouble to separate the periods, though,
it would also be reasonable to choose something a bit higher for (1), like 18-21
days, and something a bit lower for (2), like 10-12 days.
No objection on my end, I can enforce 18+ days for (1) and 14+ days for (2).
I'd note that this isn't too far from what happened in the example in
the previous mail:
(1) happened in 23 days.
(2) happened in 9 days.
--
Thanks,
Sasha
