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