Re: [Ksummit-discuss] [CORE TOPIC] checkpatch/Codingstyle and trivial patch spam

[Josh Triplett <josh@joshtriplett.org>]

On Wed, Sep 14, 2016 at 01:49:13AM +0200, Rafael J. Wysocki wrote:
> On Tuesday, September 13, 2016 02:03:22 PM Jonathan Corbet wrote:
> > On Tue, 13 Sep 2016 12:45:20 -0700
> > Josh Triplett <josh@joshtriplett.org> wrote:
> > 
> > > On Tue, Sep 13, 2016 at 08:58:49PM +0200, Christian Borntraeger wrote:
> > > > 3. CodingStyle seems to get changes which have no ACK or Reviewed-by that seem
> > > > to be controversial.  e.g.
> > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/Documentation/CodingStyle?id=865a1caa4b6b886babdd9d67e7c3608be4567a51
> > > > suggested to indent labels with a space, and was then immediately followed by
> > > > patches. Is there a process in place to verify and challenge such changes?  
> > > 
> > > Ideally, that should come up during review of the CodingStyle patch.
> > > Changes shouldn't go into CodingStyle except to document existing
> > > process and unwritten rules, or to document the results of a discussion
> > > and consensus.  That particular change to CodingStyle should have been
> > > rejected, and should be reverted.
> > 
> > So I'm quite reluctant to take CodingStyle patches for just this reason;
> > *I* certainly don't want to be the one dictating style for the kernel, but
> > I'm not really sure who does.  In my time as the docs maintainer I've only
> > applied two patches there that constitute any sort of rule change - this
> > one and a78a136fa9337fdc25fdbaa2d253f9b4dc90ad44.  
> > 
> > In general, I would welcome advice on how any future rule-change patches
> > should be reviewed.
> 
> I agree with Josh that CodingStyle should reflect the existing practice
> (present in the majority of the kernel source) or a broad consensus.
> 
> While the "existing practice" case is relatively simple (it boils down to
> demonstrating that the given rule is in fact followed in practice in the
> majority of the kernel source), the "broad consensus" one is not as
> straightforward.  It looks like a Kernel Summit discussion or equivalent
> would be required each time to be honest ...

I suspect a mailing list discussion might suffice, if enough people
weigh in with feedback.

> In any case, it might be good to state somewhere that CodingStyle is a
> guidance for new code and not a prescription for how all of the kernel code
> must look like.

Yes, the preface of the document should explicitly mention this.  "Do
not mass-reformat existing code, even if it doesn't follow these
guidelines; doing so creates noise in version control history and makes
patches fail to apply."