On Sat, Mar 11, 2023 at 12:45:20PM +0100, Pavel Machek wrote:
Hi!
I believe that -stable would be more useful without AUTOSEL process.
There has to be a way to ensure that security fixes that weren't properly tagged make it to stable anyway. So, AUTOSEL is necessary, at least in some form. I think that debating *whether it should exist* is a distraction from what's actually important, which is that the current AUTOSEL process has some specific problems, and these specific problems need to be fixed...
I agree with you, that we need autosel and we also need autosel to be better. I actually see Pavel's mail as a datapoint (or "anecdote", if you will) in support of that; the autosel process currently works so badly that a long-time contributor thinks it's worse than nothing.
Sasha, what do you need to help you make this better?
One would probably need to define "better" and "so badly". As a user of -stable kernels, I consider that they've got much better over the
Well, we have Documentation/process/stable-kernel-rules.rst . If we wanted to define "better", we should start documenting what the real rules are for the patches in the stable tree.
I agree that -stable works quite well, but the real rules are far away from what is documented.
I don't think AUTOSEL works well. I believe we should require positive reply from patch author on relevant maintainer before merging such patch to -stable.
Again, for the people in the back so that everyone can hear it, that does not work as some subsystems refuse to tag ANY patches for stable commits, nor do they want to have anything to do with stable kernels at all. And that's fine, that's their option, but because of that, we have to have a way to actually get the real fixes in those subsystems to the users who use these stable kernels. Hence, the AUTOSEL work.
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.
thanks,
greg k-h