On Fri, Apr 17, 2020 at 10:23:37PM +0000, Saeed Mahameed wrote: > On Fri, 2020-04-17 at 10:28 +0200, gregkh@xxxxxxxxxxxxxxxxxxx wrote: > > > Let me simplify: there is a bug in the AI, where it can choose a > > > wrong > > > patch, let's fix it. > > > > You do realize that there are at least 2 steps in this "AI" where > > people > > are involved. The first is when Sasha goes thorough the patches and > > weeds out all of the "bad ones". > > > > The second is when you, the maintainer, is asked if you think there > > is a > > problem if the patch is to be merged. > > > > Then there's also the third, when again, I send out emails for the > > -rc > > process with the patches involved, and you are cc:ed on it. > > > > This isn't an unchecked process here running with no human checks at > > all > > in it, so please don't speak of it like it is. > > > > Sure I understand, > > But with all do respect to Sasha and i know he is doing a great job, he > just can't sign-off on all of the patches on all of the linux kernel > and determine just by himself if a patch is good or not.. and the > maintainer review is what actually matters here. The maintainer review already happened when the patch went into Linus's tree. > But the maintainer ack is an optional thing, and I bet that the vast > majority don't even look at these e-mails. That is true. > My vision is that we make this an opt-in thing, and we somehow force > all active and important kernel subsystems to opt-in, and make it the > maintainer responsibility if something goes wrong. That's a nice vision, and I too want a pony :) Seriously, the first rule of the stable trees being created was that it was not going to cause any extra work for a maintainer to do, given that even 18 years ago, our maintainers were overloaded. Now that didn't totally happen, as I do ask for a cc: stable line to be added to patches to give me a hint as to what to apply. Now some maintainers really don't care about stable trees, and don't even put those lines, which is fine for them, but not fine for me in wanting to make stable trees that contain the needed fixes for them that are going into Linus's tree. So over the years we have come up with tools to dig these patches out of Linus's tree. The latest version of that is this AUTOSEL tool, and after a number of maintainers complained that being notified at the last possible second (i.e. during a -rc cycle) was not early enough to stop some AUTOSEL patches from being merged, Sasha started up the process you see now, giving maintainers a few _weeks_ to object. For the maintainers that don't care, fine, they just write a nice procmail rule and send the email to the round filing cabinet. For the maintainers that do care, they get a chance to object. For the maintainers that insist they are doing this all right and marking things correctly and don't want AUTOSEL running on their subsystems, they too have that option, which a few have already taken. So that's where we are today, a process that has evolved over the decades into the one that at the moment, is producing pretty solid and good stable kernels as per the review of external parties. Yes, we can do better and find more patches that need to be backported, and are working on that. But to stop and try to go to an opt-in-only process would cause us to go backwards in the ability for us to provide kernels with useful bugfixes to users. > I understand from your statistics that this system is working very > well, so i believe eventually every maintainer with a code that matters > will come on board. Sorry, that just will not happen. As proof of that, look at all of the maintainers today that are not "on board" with just a simple "cc: stable". And as I say above, that's fine, I am not going to ask them to do extra work that they do not want to do. And because of that, I, and others like Sasha, are going to have to do _extra_ work to make a better stable kernel release, and that's fine, we are the crazy ones here. > this way we don't risk it for inactive and less important > subsystems/drivers.. and we guarantee the whole thing is properly > audited with the maintainers on-board.. Have you met these maintainers that you can tell what to do despite not being their manager? If you think you can get them on board, then please, try to get them to do the simple thing first (cc: stable) and then we can talk :) good luck! greg k-h
