Re: AUTOSEL process

[Sasha Levin <sashal@kernel.org>]

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@kernel.org
>> >    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