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
