Re: fs/bcachefs/

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 22, 2024 at 06:48:58AM +0100, Greg KH wrote:
> >  - A way to unambigiously tag a patch as something that I need to look
> >    at later when I'm doing backports; and I do _not_ want to have to go
> >    git blame spelunking when I'm doing that, distracting me from
> >    whatever else I'm working on; if you insist on the Fixes: tag
> >    conforming to your tools then this won't get done and bugfixes will
> >    get lost.
> 
> Why can't you use Fixes like all of the 10's of thousands of other
> developers have over the past 15+ years?

I've explained that multiple times and you're not listening.

That's not how you work with people, Greg; cut the form letter response
bullshit and try and have a real conversation.

You've been repeatedly stonewalling and shutting down my every attempt
to find a solution here.

But honestly, this isn't even the main issue.

> And if you don't like it, that's fine, but again, you can not redefine
> it to mean something else for your tiny subsystem, sorry, that's not how
> projects of any size work well and survive.
> 
> >  - Signed pull requests to not get tweaked and rebased.
> 
> As-is, I can NOT take your signed pull request as it did not include the
> needed information in it, as I said at the time (i.e. no reference to
> the commits that you were backporting.)

You communicated that one, and I redid the cherry picks with -x...

...And they still showed up in your tree as completely different
commits.

> What I DID do is dig through your pull request and take the individual
> commits that DID apply after looking up, by hand, the proper upstream
> git commit id.  I then did NOT take the 2 commits that you had modified
> from their upstream version, as there was no indication as to why the
> changes were made, or even that any change was made at all, from what is
> in Linus's tree.  And at the time I told you all of this, so there was
> no question of what happened, and what was expected.

Why would you silently redo work that I sent you?

All you're doing is making more work for yourself. If I send you a pull
request that you can't use, kick it back to me and tell me why!

But silently redo it and drop a security fix? Can we please not?

> If I was a more paranoid person, I would have thought that the modified
> changes you sent us with no indication that the changes were modified,
> was a "supply chain attack" that you were attempting to do on us.

Of my own code?

Look, this isn't about not trusting _you_, it's that the further up the
food chain commits go the less it is possible and reasonable to expect
anything to be caught by review.

> > And please, you guys, make a bit more of an effort to work with people,
> > and listen to and address their concerns. I hear _way_ too much grousing
> > in private about -stable bullshit, and despite that I went in to this
> > optimistic that we'd be able to cut past the bullshit and establish a
> > good working relationship. Let's see if we still can...
> 
> This goes both ways please.
> 
> Again, I can not take pull requests, it does not work at all with our
> workflow as we NEED and REQUIRE actual individual commits, both for
> verification and validation, as well as to actually be able to apply to
> our trees.
> 
> We NEED and REQUIRE the git commit ids of the changes you are asking for
> including to be in the commit message itself (or somewhere that I can
> then add it), as that is how we, and everyone else, tracks what gets
> applied to where, and to be able to validate and ensure that the commit
> really is what you say it is.
> 
> We NEED and REQUIRE you, if you do modify a commit from what is in
> Linus's tree, to say "hey, this is modified because of X and Y", not to
> just not say anything and assume that we should blindly take a modified
> change.  You don't want us to do that, right?

I can provide commit messages in the format you need - but also: _none_
of this is documented in stable-kernel-rules.rst, so I'm going to want
something clear and specific I can go off of.

(And why are you not specifying the original sha1 in the format
cherry-pick -x produces? Why is that not documented?)

But not taking signed pull requests is going to be a sticking point, as
well as the fact that you only took part of the pull request.

We've had multiple bugs lately stemming from related patches not being
carried together - _nasty_ bugs, as in "I can't access my filesystem" or
"My data is being corrupted".

That was the case in this pull request too; one of the patches you
dropped, IIRC, was a locking fix for an earlier fix by Al; those patches
should have gone together.

This sort of thing is a good part of why I'm insisting on doing things
myself.

So: in the interest of avoiding issues like this, can I at least ask you
to start taking signed pull requests if the patch metadata is all in the
format you need?




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux