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?
