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 :)
> 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.)
thanks,
greg k-h
