[PATCH net 0/3] docs: netdev: document more of our rules

[PATCH net 0/3] docs: netdev: document more of our rules

[Jakub Kicinski]

The patch series length limit and reverse xmas tree are not documented.
Add those, and a tl;dr section summarizing how we differ.

Jakub Kicinski (3):
  docs: netdev: document that patch series length limit
  docs: netdev: document reverse xmas tree
  docs: netdev: add a cheat sheet for the rules

 Documentation/process/maintainer-netdev.rst | 30 +++++++++++++++++++++
 1 file changed, 30 insertions(+)

-- 
2.36.1

[PATCH net 1/3] docs: netdev: document that patch series length limit

[Jakub Kicinski]

We had been asking people to avoid massive patch series but it does
not appear in the FAQ.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/process/maintainer-netdev.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index c456b5225d66..862b6508fc22 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -136,6 +136,14 @@ it to the maintainer to figure out what is the most recent and current
 version that should be applied. If there is any doubt, the maintainer
 will reply and ask what should be done.
 
+How do I divide my work into patches?
+-------------------------------------
+
+Put yourself in the shoes of the reviewer. Each patch is read separately
+and therefore should constitute a comprehensible step towards your stated
+goal. Avoid sending series longer than 15 patches, they clog review queue
+and increase mailing list traffic when re-posted.
+
 I made changes to only a few patches in a patch series should I resend only those changed?
 ------------------------------------------------------------------------------------------
 No, please resend the entire patch series and make sure you do number your
-- 
2.36.1

[PATCH net 2/3] docs: netdev: document reverse xmas tree

[Jakub Kicinski]

Similarly to the 15 patch rule the reverse xmas tree is not
documented.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/process/maintainer-netdev.rst | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 862b6508fc22..7fb5100d195d 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -191,6 +191,19 @@ Is the comment style convention different for the networking content?
    * another line of text
    */
 
+What is "reverse xmas tree"?
+----------------------------
+
+Netdev has a convention for ordering local variables in functions.
+Order the variable declaration lines longest to shortest, e.g.::
+
+  struct scatterlist *sg;
+  struct sk_buff *skb;
+  int err, i;
+
+If there are dependencies between the variables preventing the ordering
+move the initialization out of line.
+
 I am working in existing code which uses non-standard formatting. Which formatting should I use?
 ------------------------------------------------------------------------------------------------
 Make your code follow the most recent guidelines, so that eventually all code
-- 
2.36.1

[PATCH net 3/3] docs: netdev: add a cheat sheet for the rules

[Jakub Kicinski]

Summarize the rules we see broken most often and which may
be less familiar to kernel devs who are used to working outside
of netdev.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/process/maintainer-netdev.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 7fb5100d195d..e57eb5bd3692 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -6,6 +6,15 @@
 netdev FAQ
 ==========
 
+tl;dr
+-----
+
+ - designate your patch to a tree - ``[PATCH net]`` or ``[PATCH net-next]``
+ - for fixes the ``Fixes:`` tag is required, regardless of the tree
+ - don't post large series (> 15 patches), break them up
+ - don't repost your patches within one 24h period
+ - reverse xmas tree
+
 What is netdev?
 ---------------
 It is a mailing list for all network-related Linux stuff.  This
-- 
2.36.1

Re: [PATCH net 1/3] docs: netdev: document that patch series length limit

[Andrew Lunn]

On Thu, Jun 30, 2022 at 10:46:05AM -0700, Jakub Kicinski wrote:
> We had been asking people to avoid massive patch series but it does
> not appear in the FAQ.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>  Documentation/process/maintainer-netdev.rst | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
> index c456b5225d66..862b6508fc22 100644
> --- a/Documentation/process/maintainer-netdev.rst
> +++ b/Documentation/process/maintainer-netdev.rst
> @@ -136,6 +136,14 @@ it to the maintainer to figure out what is the most recent and current
>  version that should be applied. If there is any doubt, the maintainer
>  will reply and ask what should be done.
>  
> +How do I divide my work into patches?
> +-------------------------------------
> +
> +Put yourself in the shoes of the reviewer. Each patch is read separately
> +and therefore should constitute a comprehensible step towards your stated
> +goal. Avoid sending series longer than 15 patches, they clog review queue
> +and increase mailing list traffic when re-posted.
> +

Hi Jakub

I think a key concept is, big patch series takes longer to review, so
needs a bigger junk of time allocated to it, so often gets differed
until late. As a result, it will take longer to merge. A small series
can be reviewed in a short time, so Maintainers just do it, allowing
for quicker merging.

    Andrew

Re: [PATCH net 1/3] docs: netdev: document that patch series length limit

[Jakub Kicinski]

On Fri, 1 Jul 2022 09:48:30 +0200 Andrew Lunn wrote:
> > +Put yourself in the shoes of the reviewer. Each patch is read separately
> > +and therefore should constitute a comprehensible step towards your stated
> > +goal. Avoid sending series longer than 15 patches, they clog review queue
> > +and increase mailing list traffic when re-posted.
>
> I think a key concept is, big patch series takes longer to review, so
> needs a bigger junk of time allocated to it, so often gets differed
> until late. As a result, it will take longer to merge. A small series
> can be reviewed in a short time, so Maintainers just do it, allowing
> for quicker merging.

Good point, let me fold that in.