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