Re: [git pull] drm for 5.14-rc1

From: Maxime Ripard <maxime@cerno.tech>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Michael Stapelberg <michael@stapelberg.ch>,
	Emma Anholt <emma@anholt.net>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Felix Kuehling <felix.kuehling@amd.com>,
	Dave Airlie <airlied@gmail.com>
Subject: Re: [git pull] drm for 5.14-rc1
Date: Wed, 22 Sep 2021 13:54:12 +0200	[thread overview]
Message-ID: <20210922115412.ectgjtyhgmeaxqxn@gilmour> (raw)
In-Reply-To: <CAHk-=wgOvmtRw1TNbMC1rn5YqyTKyn0hz+sc4k0DGNn++u9aYw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On Mon, Sep 20, 2021 at 10:47:43AM -0700, Linus Torvalds wrote:
> 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.

Ok.

> 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 still don't have a way to reproduce Sudip's bug, so I can't even
provide that.

> 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.

It's not really about drm here, it's a dependency on the clock framework.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]