On Thu, Apr 16, 2020 at 3:00 AM Sasha Levin sashal@kernel.org wrote:
I'd maybe point out that the selection process is based on a neural network which knows about the existence of a Fixes tag in a commit.
It does exactly what you're describing, but also taking a bunch more factors into it's desicion process ("panic"? "oops"? "overflow"? etc).
As Saeed commented, every extra line in stable / production kernel is wrong. IMHO it doesn't make any sense to take into stable automatically any patch that doesn't have fixes line. Do you have 1/2/3/4/5 concrete examples from your (referring to your Microsoft employee hat comment below) or other's people production environment where patches proved to be necessary but they lacked the fixes tag - would love to see them.
We've been coaching new comers for years during internal and on-list code reviews to put proper fixes tag. This serves (A) for the upstream human review of the patch and (B) reasonable human stable considerations.
You are practically saying that for cases we screwed up stage (A) you can somehow still get away with good results on stage (B) - I don't accept it. BTW - during my reviews I tend to ask/require developers to skip the word panic, and instead better explain the nature of the problem / result.
This is great, but the kernel is more than just net/. Note that I also do not look at net/ itself, but rather drivers/net/ as those end up with a bunch of missed fixes.
drivers/net/ goes through the same DaveM net/net-next trees, with the same rules.
you ignored this comment, any more specific complaints?
Let me put my Microsoft employee hat on here. We have driver/net/hyperv/ which definitely wasn't getting all the fixes it should have been getting without AUTOSEL.
While net/ is doing great, drivers/net/ is not. If it's indeed following the same rules then we need to talk about how we get done right.
I never [1] saw -stable push requests being ignored here in netdev. Your drivers have four listed maintainers and it's common habit by commercial companies to have paid && human (non autosel robots) maintainers that take care of their open source drivers. As in commercial SW products, Linux has a current, next and past (stable) releases, so something sounds as missing to me in your care matrix.
[1] actually I do remember that once or twice out of the 2020 times we asked, a patch was not sent to -stable by the sub-system maintainer mistake which he fixed(..) later