On Tue, Feb 20, 2024 at 03:22:59PM -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.
Then there's a gap, because I need a tag that I can stick in a commit message that says "this is a bugfix I need to consider backporting later", and the way you want the Fixes: tag used doesn't meet my needs.
Then use patchwork or something else, but please do not override a 15+ year old tag for just one small portion of the kernel.
Or better yet, use the fixes: tag with the commit id you are fixing, that way all other kernel workflows work properly with this filesystem. No need to be unique here :)
thanks,
greg k-h