On Tue, Feb 20, 2024 at 09:51:20PM +0100, Greg KH wrote:
On Tue, Feb 20, 2024 at 03:39:16PM -0500, Kent Overstreet wrote:
On Tue, Feb 20, 2024 at 09:19:01PM +0100, Greg KH wrote:
On Tue, Feb 20, 2024 at 03:06:14PM -0500, Kent Overstreet wrote:
On Tue, Feb 20, 2024 at 07:53:04PM +0100, Greg KH wrote:
On Tue, Feb 20, 2024 at 07:03:23PM +0100, Greg KH wrote:
On Tue, Feb 20, 2024 at 12:23:33PM -0500, Kent Overstreet wrote: > On Mon, Jan 15, 2024 at 06:03:11PM -0500, Sasha Levin wrote: > > On Mon, Jan 15, 2024 at 05:12:17PM -0500, Kent Overstreet wrote: > > > Hi stable team - please don't take patches for fs/bcachefs/ except from > > > myself; I'll be doing backports and sending pull requests after stuff > > > has been tested by my CI. > > > > > > Thanks, and let me know if there's any other workflow things I should > > > know about > > > > Sure, we can ignore fs/bcachefs/ patches. > > I see that you even acked this. > > What the fuck?
Accidents happen, you were copied on those patches. I'll go drop them now, not a big deal.
Wait, why are you doing "Fixes:" with an empty tag in your commits like 1a1c93e7f814 ("bcachefs: Fix missing bch2_err_class() calls")?
That's messing with scripts and doesn't make much sense. Please put a real git id in there as the documentation suggests to.
There isn't always a clear-cut commit when a regression was introduced (it might not have been a regresison at all). I could dig and make something up, but that's slowing down your workflow, and I thought I was going to be handling all the stable backports for fs/bcachefs/, so - ?
Doesn't matter, please do not put "fake" tags in commit messages like this. It hurts all of the people that parse commit logs. Just don't put a fixes tag at all as the documentation states that after "Fixes:" a commit id belongs.
So you manually repicked a subset of my pull request, and of the two patches you silently dropped, one was a security fix - and you _never communicated_ what you were doing.
I explicitly said "Not all of these applied properly, please send me the remaining ones". I can go back and get the message-id if you want reciepts :)
I gave you a _signed pull request_, and there were no merge conflicts.
Greg, this isn't working. How are we going to fix this?
Please send a set of backported commits that you wish to have applied to the stable trees. All other subsystems do this fairly easily, it's no different from sending a patch series out for anything else.
Worst case, I can take a git tree, BUT I will then turn that git tree into individual commits as that is what we MUST deal with for the stable trees, we can not work with direct pull requests for obvious reasons of how the tree needs to be managed (i.e. rebasing all the time would never work.)
You rebase these trees? Why? Are they not public?
Look, I need to know that the code I send you is the same as the code that gets published in stable releases. If you're going to be rebasing the trees I send you, _all_ the mechanisms we have for doing that validation break and I'm back to manual verification.
And given that we've got mechanisms for avoiding that - not rebasing so that we can verify by the sha1, gpg signing - why is stable special here?