Re: [git pull] drm for 5.14-rc1

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, Sep 20, 2021 at 10:33 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> What I was interested in was more about the context itself, and I'd
> still like an answer on whether it's ok to wait for a review for 5
> months though, or if it's an expectation from now on that we are
> supposed to fix bugs over the week-end.

Oh, it's definitely not "over a weekend". These reverts happened on a
Sunday just because that's when I do rc releases, and this was one of
those pending issues that had been around long enough that I went "ok,
I'm reverting now since it's been bisected and verified".

So it happened on a weekend, but that's pretty incidental.

You should not wait for 5 months to send bug-fixes. That's not the
point of review, and review shouldn't hold up reported regressions of
existing code. That's just basic _testing_ - either the fix should be
applied, or - if the fix is too invasive or too ugly - the problematic
source of the regression should be reverted.

Review should be about new code, it shouldn't be holding up "there's a
bug report, here's the obvious fix".

And for something like a NULL pointer dereference, there really should
generally be an "obvious fix".

Of course, a corollary to that "fixes are different from new
development", though, is that bug fixes need to be kept separate from
new code - just so that they _can_ be handled separately and so that
you could have sent Sudip (and Michael, although that was apparently a
very different bug, and the report came in later) a "can you test this
fix" kind of thing.

I don't know what the review issue on the vc4 drm side is, but I
suspect that the vc4 people are just perhaps not as integrated with a
lot of the other core drm people. Or maybe review of new features are
held off because there are bug reports on the old code.

                   Linus