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. (Even just stable-kernel-rules.rst is totally incorrect these days.) 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've been playing with this in the past - I had a bot that looks at the > mailing lists for patches that are tagged for stable, and attempts to > apply/build then on the multiple trees to verify that it works and send > a reply back if something goes wrong, asking for a backport. > > It gets a bit tricky as there's no way to go back from a commit to the > initial submission, you start hitting issues like: > > - Patches get re-sent multiple times (think stuff like tip trees, > reviews from other maintainers, etc). > - Different versions of patches - for example, v1 was a single patch > and in v2 it became multiple patches. > > I'm not arguing against your idea, I'm just saying that it's not > trivial. An incomplete work here simply won't scale to the thousands of > patches that flow in the trees, and won't be as useful. I don't think > that this is trivial as you suggest. There are obviously going to be edge cases; another one is commits that show up in git without ever having been sent to the mailing list. I don't think they actually matter very much, though. Worst case, we miss some things, but still find everything else. > > If you disagree, and really think it's trivial, take 5 minutes to write > something up? please? I never said that it's "trivial" or that it would take only 5 minutes; that's just silly. Just that this is possible and it's what needs to be done. If you don't have time, you should instead be helping ensure that the work gets done by someone else (internship, GSoC project, etc.). And yes, I am interested in contributing, but as I mentioned I think you need to first acknowledge that there is a problem, fix your attitude of immediately pushing back on everything, and make it easier for people to contribute. - Eric
