From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7405CA9EBB for ; Thu, 24 Oct 2019 17:31:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B74C420650 for ; Thu, 24 Oct 2019 17:31:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2503789AbfJXRbN (ORCPT ); Thu, 24 Oct 2019 13:31:13 -0400 Received: from mga12.intel.com ([192.55.52.136]:33122 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729458AbfJXRbM (ORCPT ); Thu, 24 Oct 2019 13:31:12 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Oct 2019 10:31:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,225,1569308400"; d="scan'208";a="282008162" Received: from nesterov-mobl1.ccr.corp.intel.com (HELO localhost) ([10.252.8.153]) by orsmga001.jf.intel.com with ESMTP; 24 Oct 2019 10:30:52 -0700 Date: Thu, 24 Oct 2019 20:30:51 +0300 From: Jarkko Sakkinen To: Mark Salyzyn Cc: linux-kernel@vger.kernel.org, kernel-team@android.com, "David S. Miller" , Jonathan Corbet , Ard Biesheuvel , Harry Wentland , Leo Li , Alex Deucher , Christian =?iso-8859-1?Q?K=F6nig?= , "David (ChunMing) Zhou" , David Airlie , Daniel Vetter , VMware Graphics , Thomas Hellstrom , Laurent Pinchart , Mauro Carvalho Chehab , Trond Myklebust , Anna Schumaker , Alexander Aring , Jukka Rissanen , Alexey Kuznetsov , Hideaki YOSHIFUJI , Ingo Molnar , Matthew Garrett , Hans de Goede , hersen wu , Roman Li , Maxim Martynov , David Ahern , Francesco Ruggeri , Linus =?iso-8859-1?Q?L=FCssing?= , Greg Kroah-Hartman , Feng Tang , "Steven Rostedt (VMware)" , Andrew Morton , Rafael Aquini , netdev@vger.kernel.org, linux-doc@vger.kernel.org, linux-efi@vger.kernel.org, amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org, linux-nfs@vger.kernel.org, linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org Subject: Re: [PATCH] Cleanup: replace prefered with preferred Message-ID: <20191024173051.GB7948@linux.intel.com> References: <20191022214208.211448-1-salyzyn@android.com> <20191023115637.GA23733@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-wpan-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wpan@vger.kernel.org On Wed, Oct 23, 2019 at 08:40:59AM -0700, Mark Salyzyn wrote: > On 10/23/19 4:56 AM, Jarkko Sakkinen wrote: > > On Tue, Oct 22, 2019 at 02:41:45PM -0700, Mark Salyzyn wrote: > > > Replace all occurrences of prefered with preferred to make future > > > checkpatch.pl's happy. A few places the incorrect spelling is > > > matched with the correct spelling to preserve existing user space API. > > > > > > Signed-off-by: Mark Salyzyn > > I'd fix such things when the code is otherwise change and scope this > > patch only to Documentation/. There is no pragmatic benefit of doing > > this for the code. > > > > /Jarkko > > The pragmatic benefit comes with the use of an ABI/API checker (which is a > 'distro' thing, not a top of tree kernel thing) produces its map which is > typically required to be co-located in the same tree as the kernel > repository. Quite a few ABI/API update checkins result in a checkpatch.pl > complaint about the misspelled elements being (re-)recorded due to > proximity. We have a separate task to improve how it is tracked in Android > to reduce milepost marker changes that result in sweeping changes to the > database which would reduce the occurrences. > > I will split this between pure and inert documentation/comments for now, > with a followup later for the code portion which understandably is more > controversial. > > Cleanup is the least appreciated part of kernel maintenance ;-}. > > Sincerely -- Mark Salyzyn I'm a strong believer of "evolutionary" approach. Patch sets for the most part (everything in the end has to be considered case by case, not a strict rule) should have some functional changes involved. What I do require for the parts that I maintain is that any new change will result cleaner code base than the one that existed before that change was applied. Again, there are some exceptions to this e.g. circulating a firmware bug but this is my driving guideline as a maintainer. Doing cleanups just for cleanups can sometimes add unnecessary merge conflicts when backporting patches to stable kernels. Thus, if you are doing just a cleanup you should have extremely good reasons to do so. /Jarkko