lkml.org 
[lkml]   [2017]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program
    From
    Date
    On Mon, 2017-12-18 at 17:56 +0000, Bart Van Assche wrote:
    > On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
    > > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
    > >
    > > > > Today when we run checkers we get so many warnings it is too hard to
    > > > > make any sense of it.
    > > >
    > > > Here is a list of the checkpatch messages for drivers/infiniband
    > > > sorted by type.
    > > >
    > > > Many of these might be corrected by using
    > > >
    > > > $ ./scripts/checkpatch.pl -f --fix-inplace --types=<TYPE> \
    > > > $(git ls-files drivers/infiniband/)
    > >
    > > How many of these do you think it is worth to fix?
    > >
    > > We do get a steady trickle of changes in this topic every cycle.
    > >
    > > Is it better to just do a big number of them all at once? Do you have
    > > an idea how disruptive this kind of work is to the whole patch flow
    > > eg new patches no longer applying to for-next, backports no longer
    > > applying, merge conflicts?
    >
    > In my opinion patches that only change the coding style and do not change any
    > functionality are annoying. Before posting a patch that fixes a bug the change
    > history (git log -p) has to be cheched to figure out which patch introduced
    > the bug. Patches that only change coding style pollute the change history.

    I agree with you - the problem is that style issues should not have existed.
    But when they do it becomes a problem to remove them and a problem to
    keep them - for instance us who try to be compliant by having style helpers
    in our editor, we end up having to manually revert old style mistakes back in
    to avoid making unrelated whitespace changes or similar.

    I think what we get with this patch set is that there's a way to rein in the
    issues and to enable some regression testing without enforcing a lot of work
    or annoying history issues *right away*. That way this problem can be tackled when
    appropriate for the subsystem in question, and the reason for holding back on
    some changes can be documented in the local runchecks.cfg file, focusing
    willing helping hands on the issues considered most important for that
    subsystem.

    Thanks,
    Knut

    \
     
     \ /
      Last update: 2017-12-18 19:41    [W:3.442 / U:0.696 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site