On Sat, Mar 11, 2023 at 10:54:59AM -0800, Eric Biggers wrote: > On Sat, Mar 11, 2023 at 01:26:57PM -0500, Sasha Levin wrote: > > > > "job"? do you think I'm paid to do this work? > > > Why would I stonewall improvements to the process? > > > > I'm getting a bunch of suggestions and complaints that I'm not implementing > > those suggestions fast enough on my spare time. > > > > > One of the first things I would do if I was maintaining the stable kernels is to > > > set up a way to automatically run searches on the mailing lists, and then take > > > advantage of that in the stable process in various ways. Not having that is the > > > root cause of a lot of the issues with the current process, IMO. > > > > "if I was maintaining the stable kernels" - why is this rellevant? give > > us the tool you've proposed below and we'll be happy to use it. Heck, > > don't give it to us, use it to review the patches we're sending out for > > review and let us know if we've missed anything. > > It's kind of a stretch to claim that maintaining the stable kernels is not part > of your and Greg's jobs. But anyway, the real problem is that it's currently > very hard for others to contribute, given the unique role the stable maintainers > have and the lack of documentation about it. Each of the two maintainers has > their own scripts, and it is not clear how they use them and what processes they > follow. Just a comment here about our scripts and process. Our scripts are different as we both currently do different things for the stable trees. I have almost no scripts for finding patches, all I use is a git hook that dumps emails into a mbox and then go through them and queue them up to the quilt trees based on if they are valid or not after review. My scripts primarily are for doing a release, not building the patches up. That being said, I do have 2 scripts I use to run on an existing tree or series to verify that the fixes are all present already (i.e. if we have fixes for the fixes), but that's not really relevant for this discussion. Those, and my big "treat the filesystem as a git database" hack can be found in this repo: https://git.sr.ht/~gregkh/linux-stable_commit_tree/ if you are curious, these are probably the relevant scripts if you are curious: https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/find_fixes_in_queue https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/find_fixes_in_range And I use: https://git.sr.ht/~gregkh/linux-stable_commit_tree/tree/master/item/id_found_in all the time to determine if a SHA1 is in any stable releases. > (Even just stable-kernel-rules.rst is totally incorrect these days.) I do not understand this, what is not correct? It's how to get patches merged into stable kernels, we go above-and-beyond that for those developers and maintainers that do NOT follow those rules. If everyone followed them, we wouldn't be having this discussion at all :) > Actually I still don't even know where your scripts are! They are not in > stable-queue/scripts, it seems those are only Greg's scripts? And if I built > something, how do I know you would even use it? You likely have all sorts of > requirements that I don't even know about. I think what you are talking about here would require new work. New tools to dig in the commits to extract "here's the whole series of patches" would be wonderful, but as others have pointed out, it is _very_ common to have a cc: stable as the first few commits in a series, and then the rest have nothing to do with a stable tree. But when doing something like what AUTOSEL does, digging up the whole series would be great. We have tools that can match up every commit in the tree to a specific email message (presentations on the tool and how it works have been a previous LinuxCon conferences), but if we can use lore.kernel.org for it, that would probably help everyone out. And that's why I use the Link: tag, as Ted pointed out, for everything that I apply to all of the subsystems I work with. While I know Linus doesn't like it, I think it is quite valuable as it makes it so that _anyone_ can instantly find the thread where the patch came from, and no external tools are required. Anyway, as always, I gladly accept help with figuring out what commits to apply to stable kernels. I've always said this, and Sasha has stepped up in an amazing way here over the years, creating tools based on collaboration with many others (see his presentations at conferences with Julia) on how to dig into the kernel repo to find patches that we all forget to tag for stable kernels and he sends them out for review. If you want to help out and do much the same thing using different sorts of tools, or come up with other ways of finding the bugfixes that are in there that are not properly tagged, wonderful, I will gladly accept them, I have never turned down help like this. And that's what I ask from companies all the time when they say "what can we do to help out?" A simple thing to do is dig in your vendor trees and send me the fixes that you have backported there. I know distros have this (and some distros help out and do this, I'll call out Debian for being very good here), and some companies do submit their backports as well (Amazon and Hawaii are good, Android also does a good job), but they are rare compared to all of the groups that I know use Linux. Anyway, if anyone noticed the big problems this weekend with the stable releases were due to patches that were actually tagged with "cc: stable" so that's kind of proof that we all are human and even when we think a fix is enough, it can cause problems when it hits real world testing. We are all human, the best we can do is when confronted with "hey, this fix causes a problem" is revert it and get the fix out to people as quick as possible. That includes fixes picked from tools like AUTOSEL as well as manual tags, there is no difference here in our response. thanks, greg k-h
