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?