On Thu, 2020-04-16 at 15:53 -0400, Sasha Levin wrote: > On Thu, Apr 16, 2020 at 07:31:25PM +0000, Saeed Mahameed wrote: > > On Thu, 2020-04-16 at 19:20 +0200, Greg KH wrote: > > > So far the AUTOSEL tool has found so many real bugfixes that it > > > isn't > > > funny. If you don't like it, fine, but it has proven itself > > > _way_ > > > beyond my wildest hopes already, and it just keeps getting > > > better. > > > > > > > Now i really don't know what the right balance here, in on one > > hand, > > autosel is doing a great job, on the other hand we know it can > > screw up > > in some cases, and we know it will. > > > > So we decided to make sacrifices for the greater good ? :) > > autosel is going to screw up, I'm going to screw up, you're going to > screw up, and Linus is going screw up. The existence of the stable > trees > and a "Fixes:" tag is an admission we all screw up, right? > Right, so fix this AI and we get one less reason to screw up ? > If you're willing to accept that we all make mistakes, you should > also > accept that we're making mistakes everywhere: we write buggy code, we > fail at reviews, we forget tags, and we suck at backporting patches. > > 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.. I am not saying people should be 100% flawless, but i am assuming AI is 100% flawless. if I find a bug in AI I fix. same goes for autosel AI, it must get fixed. What you are really saying: I don't like bugs, so i wrote an AI that fixes bugs but also can make bugs itself. > > My view of the the path forward with stable trees is that we have to > beef up our validation and testing story to be able to catch these > issues better, rather than place arbitrary limitations on parts of > the > process. To me your suggestions around the Fixes: tag sound like > "Never > use kmalloc() because people often forget to free memory!" will it > prevent memory leaks? sure, but it'll also prevent useful patches > from > coming it... > No, I will let people do what people do best (make more bugs) this is more than fine. 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. 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. You are welling to roll the dice, i am not .. > 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 ?
