On Thu, 2020-04-16 at 19:23 -0400, Sasha Levin wrote:
On Thu, Apr 16, 2020 at 09:32:47PM +0000, Saeed Mahameed wrote:
On Thu, 2020-04-16 at 15:53 -0400, Sasha Levin wrote:
If we agree so far, then why do you assume that the same people who do the above also perfectly tag their commits, and do perfect selection of patches for stable? "I'm always right except when I'm wrong".
I am welling to accept people making mistakes, but not the AI..
This is where we disagree. If I can have an AI that performs on par with an "average" kernel engineer - I'm happy with it.
The way I see AUTOSEL now is an "average" kernel engineer who does patch sorting for me to review.
Given I review everything that it spits out at me, it's technically a human error (mine), rather than a problem with the AI, right?
if it is necessary and we have a magical solution, i will write good AI with no false positives to fix or help avoid memleacks.
Easier said than done :)
I think that the "Intelligence" in AI suggests that it can be making mistakes.
BUT if i can't achieve 100% success rate, and i might end up introducing memleack with my AI, then I wouldn't use AI at all.
We have different views on things.. if i know AI is using kmalloc wrongly, I fix it, end of story :).
fact: Your AI is broken, can introduce _new_ un-called for bugs, even it is very very very good 99.99% of the cases.
People are broken too, they introduce new bugs, so why are we accepting new commits into the kernel?
My point is that everything is broken, you can't have 100% perfect anything.
Here's my suggestion: give us a test rig we can run our stable release candidates through. Something that simulates "real" load that customers are using. We promise that we won't release a stable kernel if your tests are failing.
I will be more than glad to do so, is there a formal process for such thing ?
I'd love to work with you on this if you're interested. There are a few options:
- Send us a mail when you detect a push to a stable-rc branch. Most
people/bots reply to Greg's announce mail with pass/fail.
Sounds like our best option for now, as we already have our own testing infra that knows how to watch for external changes in mailing lists.
- Integrate your tests into kernelci (kernelci.org) - this means
that you'll run a "lab" on prem, and kernelci will schedule builds and tests on it's own, sending reports to us.
- We're open to other solutions if you had something in mind, the
first two usually work for people but if you have a different requirement we'll be happy to figure it out.
Thanks,
I will have to discuss this with our CI maintainers and see what we prefer.
i will let you know.