On Thu, Feb 22, 2024 at 06:48:58AM +0100, Greg KH wrote: > > - A way to unambigiously tag a patch as something that I need to look > > at later when I'm doing backports; and I do _not_ want to have to go > > git blame spelunking when I'm doing that, distracting me from > > whatever else I'm working on; if you insist on the Fixes: tag > > conforming to your tools then this won't get done and bugfixes will > > get lost. > > Why can't you use Fixes like all of the 10's of thousands of other > developers have over the past 15+ years? I've explained that multiple times and you're not listening. That's not how you work with people, Greg; cut the form letter response bullshit and try and have a real conversation. You've been repeatedly stonewalling and shutting down my every attempt to find a solution here. But honestly, this isn't even the main issue. > And if you don't like it, that's fine, but again, you can not redefine > it to mean something else for your tiny subsystem, sorry, that's not how > projects of any size work well and survive. > > > - Signed pull requests to not get tweaked and rebased. > > As-is, I can NOT take your signed pull request as it did not include the > needed information in it, as I said at the time (i.e. no reference to > the commits that you were backporting.) You communicated that one, and I redid the cherry picks with -x... ...And they still showed up in your tree as completely different commits. > What I DID do is dig through your pull request and take the individual > commits that DID apply after looking up, by hand, the proper upstream > git commit id. I then did NOT take the 2 commits that you had modified > from their upstream version, as there was no indication as to why the > changes were made, or even that any change was made at all, from what is > in Linus's tree. And at the time I told you all of this, so there was > no question of what happened, and what was expected. Why would you silently redo work that I sent you? All you're doing is making more work for yourself. If I send you a pull request that you can't use, kick it back to me and tell me why! But silently redo it and drop a security fix? Can we please not? > If I was a more paranoid person, I would have thought that the modified > changes you sent us with no indication that the changes were modified, > was a "supply chain attack" that you were attempting to do on us. Of my own code? Look, this isn't about not trusting _you_, it's that the further up the food chain commits go the less it is possible and reasonable to expect anything to be caught by review. > > And please, you guys, make a bit more of an effort to work with people, > > and listen to and address their concerns. I hear _way_ too much grousing > > in private about -stable bullshit, and despite that I went in to this > > optimistic that we'd be able to cut past the bullshit and establish a > > good working relationship. Let's see if we still can... > > This goes both ways please. > > Again, I can not take pull requests, it does not work at all with our > workflow as we NEED and REQUIRE actual individual commits, both for > verification and validation, as well as to actually be able to apply to > our trees. > > We NEED and REQUIRE the git commit ids of the changes you are asking for > including to be in the commit message itself (or somewhere that I can > then add it), as that is how we, and everyone else, tracks what gets > applied to where, and to be able to validate and ensure that the commit > really is what you say it is. > > We NEED and REQUIRE you, if you do modify a commit from what is in > Linus's tree, to say "hey, this is modified because of X and Y", not to > just not say anything and assume that we should blindly take a modified > change. You don't want us to do that, right? I can provide commit messages in the format you need - but also: _none_ of this is documented in stable-kernel-rules.rst, so I'm going to want something clear and specific I can go off of. (And why are you not specifying the original sha1 in the format cherry-pick -x produces? Why is that not documented?) But not taking signed pull requests is going to be a sticking point, as well as the fact that you only took part of the pull request. We've had multiple bugs lately stemming from related patches not being carried together - _nasty_ bugs, as in "I can't access my filesystem" or "My data is being corrupted". That was the case in this pull request too; one of the patches you dropped, IIRC, was a locking fix for an earlier fix by Al; those patches should have gone together. This sort of thing is a good part of why I'm insisting on doing things myself. So: in the interest of avoiding issues like this, can I at least ask you to start taking signed pull requests if the patch metadata is all in the format you need?