Mailing List Archive

On Sun 12-03-23 00:09:47, Theodore Ts'o wrote:
> On Sun, Mar 12, 2023 at 05:41:07AM +0100, Willy Tarreau wrote:
> >
> > I suspect that having an option to keep the message ID in the footer (a
> > bit like the "cherry-picked from" tag but instead "blongs to series")
> > could possibly help. And when no such info is present we could have
> > one ID generated per "git am" execution since usually if you apply an
> > mbox, it constitutes a series (but not always of course, though it's
> > not difficult to arrange series like this).
>
> As I pointed out earlier, some of us are adding the message ID in the
> footer alrady, using a Link tag. This is even documented already in
> the Kernel Maintainer's Handbook, so I'm pretty sure it's not just me. :-)

Yeah, given Linus' rants about links pointing to patch posting, what I'm
currently doing is that I add Message-ID: tag to the patch instead of a
Link: tag. It preserves the information as well and it is obvious to human
reader what are links to reports / discussions and what is just a link to
patch posting.

Honza

--
Jan Kara <jack@suse.com>
SUSE Labs, CR

On Mon, Mar 13, 2023 at 11:54:17AM -0700, Eric Biggers wrote:
>
> The fact is, many people *do* follow the rules exactly by *not* tagging commits
> for stable when they don't meet the documented eligibility criteria. But then
> the stable maintainers backport the commits anyway, as the real eligibility
> criteria are *much* more relaxed than what is documented.

Again, if you do NOT want your patches backported, because you always
mark them properly for stable releases, just let us know and we will add
you to the list of other subsystems and maintainers that have asked us
for this in the past.

We can't detect the absence of a tag as "I know exactly what I am doing"
because of the huge number of developers who do NOT tag patches, and so,
we have to dig through the tree to find fixes on our own.

thanks,

greg k-h

On Sat, 11 Mar 2023, Greg KH wrote:

> So no, forcing a maintainer/author to ack a patch to get it into stable
> is not going to work UNLESS a maintainer/author explicitly asks for
> that, which some have, and that's wonderful.

FWIW I'm happy to ack patches for stable backporting (and I tag patches
of mine for stable as I deem appropriate).

Maciej

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?

I hope you can understand why I have to ask you --- you are the only person who
can change your own policy.

Thanks,

- Eric

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?

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

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.

- Eric

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