Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Thu, 2019-06-13 at 08:21 -0700, Bart Van Assche wrote:
> On 6/13/19 8:03 AM, Martin K. Petersen wrote:
> > 
> > James,
> > 
> > > It depends: every patch you do to an old driver comes with a risk
> > > of breakage.  What we've found is even apparently sane patches
> > > cause breakage which isn't discovered until months later when
> > > someone with the hardware actually tests.
> > 
> > My pet peeve is with the constant stream of seemingly innocuous
> > helper-interface-of-the-week changes. Such as "Use kzfoobar()
> > instead of kfoobar() + memset()". And then a year later somebody
> > decides kzfoobar() had a subtle adverse side-effect and now we all
> > need to switch to kpzfoobar().
> > 
> > I appreciate that some of these helpers may have merit in terms of
> > facilitating static code checkers, etc. But other than that, I
> > really fail to see the value of this constant churn.
> > 
> > The devil is always in the details. It's almost inevitably these
> > obvious five-liners that cause regressions down the line.
> > 
> > So why do we keep doing this?
> 
> How about discussing at the kernel summit whether or not patches
> that have not been tested on actual hardware should be ignored?

Might be a bit harsh, but perhaps "must be tested on hardware or
provably not change the binary or be part of a treewide update" might
be a reasonable rule to shoot for.  However, this would
disproportionately affect the security and coccinelle people because
they do one patch at a time stuff for which they definitely don't have
hardware, so for maintained drivers they could submit to the maintainer
for update and testing, but we'd be disallowing their changes for
unmaintained drivers.

James