netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Simon Horman <horms@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Jonathan Corbet <corbet@lwn.net>,
	netdev@vger.kernel.org, workflows@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH RFC net] docs: netdev: document guidance on cleanup patches
Date: Mon, 7 Oct 2024 08:24:30 -0700	[thread overview]
Message-ID: <20241007082430.21de3848@kernel.org> (raw)
In-Reply-To: <20241004-doc-mc-clean-v1-1-20c28dcb0d52@kernel.org>

On Fri, 04 Oct 2024 10:49:53 +0100 Simon Horman wrote:
> The purpose of this section is to document what is the current practice
> regarding clean-up patches which address checkpatch warnings and similar
> problems. I feel there is a value in having this documented so others
> can easily refer to it.
> 
> Clearly this topic is subjective. And to some extent the current
> practice discourages a wider range of patches than is described here.
> But I feel it is best to start somewhere, with the most well established
> part of the current practice.
> 
> --
> I did think this was already documented. And perhaps it is.
> But I was unable to find it after a quick search.

Thanks a lot for documenting it, this is great!
All the suggestions below are optional, happy to merge as is.

> +Clean-Up Patches
> +~~~~~~~~~~~~~~~~

nit: other sections use sentence-like capitalization (only capitalizing
the first word), is that incorrect? Or should we ay "Clean-up patches"
here?

> +Netdev discourages patches which perform simple clean-ups, which are not in
> +the context of other work. For example addressing ``checkpatch.pl``
> +warnings, or :ref:`local variable ordering<rcs>` issues. This is because it
> +is felt that the churn that such changes produce comes at a greater cost
> +than the value of such clean-ups.

Should we add "conversions to managed APIs"? It's not a recent thing,
people do like to post patches doing bulk conversions which bring very
little benefit.

On the opposite side we could mention that spelling fixes are okay.
Not sure if that would muddy the waters too much..

  reply	other threads:[~2024-10-07 15:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-04  9:49 [PATCH RFC net] docs: netdev: document guidance on cleanup patches Simon Horman
2024-10-07 15:24 ` Jakub Kicinski [this message]
2024-10-07 15:55   ` Simon Horman
2024-10-07 16:08     ` Jakub Kicinski
2024-10-07 16:15       ` Simon Horman
2024-10-07 16:54         ` Jakub Kicinski
2024-10-08 12:30           ` Simon Horman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241007082430.21de3848@kernel.org \
    --to=kuba@kernel.org \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).