Documentation/process/maintainer-netdev.rst

1 .. SPDX-License-Identifier: GPL-2.0
3 .. _netdev-FAQ:
10 -----
12  - designate your patch to a tree - ``[PATCH net]`` or ``[PATCH net-next]``
13  - for fixes the ``Fixes:`` tag is required, regardless of the tree
14  - don't post large series (> 15 patches), break them up
15  - don't repost your patches within one 24h period
16  - reverse xmas tree
19 ------
21 netdev is a mailing list for all network-related Linux stuff.  This
31 Aside from subsystems like those mentioned above, all network-related
36 -----------------
42 merge window is closed, and it is called/tagged ``-rc1``.  No new
43 features get mainlined after this -- only fixes to the rc1 content are
47 state of churn), and a week after the last vX.Y-rcN was done, the
50 To find out where we are now in the cycle - load the mainline (Linus)
58 (without an ``-rcN`` suffix) - we are most likely in a merge window
59 and ``net-next`` is closed.
61 git trees and patch flow
62 ------------------------
66 ``net`` tree, and the ``net-next`` tree.  As you can probably guess from
68 mainline tree from Linus, and ``net-next`` is where the new code goes
71 - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git
72 - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
74 Relating that to kernel development: At the beginning of the 2-week
75 merge window, the ``net-next`` tree will be closed - no new changes/features.
77 mainline/Linus via a pull request for vX.Y -- at the same time, the
81 An announcement indicating when ``net-next`` has been closed is usually
85   Do not send new ``net-next`` content to netdev during the
86   period during which ``net-next`` tree is closed.
89 (use ``--subject-prefix='RFC net-next'`` with ``git format-patch``).
91 Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
92 tree for ``net-next`` reopens to collect content for the next (vX.Y+1)
96 ``net-next`` has re-opened yet, simply check the ``net-next`` git
97 repository link above for any new networking-related commits.  You may
100   https://netdev.bots.linux.dev/net-next.html
108 netdev patch review
109 -------------------
113 Patch status
116 Status of a patch can be checked by looking at the main patchwork
122 patch:
125 Patch state        Description
127 New, Under review  pending review, patch is in the maintainer’s queue for
129                    the exact co-maintainer handling patchwork at the time)
130 Accepted           patch was applied to the appropriate networking tree, this is
131                    usually set automatically by the pw-bot
133 Changes requested  patch has not passed the review, new revision is expected
135 Rejected           patch has been rejected and new revision is not expected
136 Not applicable     patch is expected to be applied outside of the networking
138 Awaiting upstream  patch should be reviewed and handled by appropriate
139                    sub-maintainer, who will send it on to the networking trees;
141                    will usually remain in this state, whether the sub-maintainer
142                    requested changes, accepted or rejected the patch
143 Deferred           patch needs to be reposted later, usually due to dependency
145 Superseded         new version of the patch was posted, usually set by the
146                    pw-bot
148                    pw-bot can automatically set patches to this state based
152 Patches are indexed by the ``Message-ID`` header of the emails
153 which carried them so if you have trouble finding your patch append
154 the value of ``Message-ID`` to the URL above.
156 Updating patch status
159 Contributors and reviewers do not have the permissions to update patch
169   pw-bot: changes-requested
181 header on patch submission and command must match!), maintainers of
187   https://netdev.bots.linux.dev/pw-bot.html
193 48h). But be patient, if your patch is active in patchwork (i.e. it's
194 listed on the project's patch list) the chances it was missed are close to zero.
198 are very unlikely to arrive after a week of silence. If a patch
200 than a week - clarify the next steps and/or post the next version.
202 For RFC postings specifically, if nobody responded in a week - reviewers
204 repost as a PATCH.
207 out the status of the patch from patchwork or where the discussion has
208 landed - describe your best guess and ask if it's correct. For example::
222   [PATCH net-next v3] net: make cows go moo
229   Signed-off-by: Joe Defarmer <joe@barn.org>
230   ---
232     - add a note about time-of-day mooing fluctuation to the commit message
234     - fix missing argument in kernel doc for netif_is_bovine()
235     - fix memory leak in netdev_register_cow()
245 Please always resend the entire patch series and make sure you do number your
252 Occasionally a patch series gets applied before receiving critical feedback,
255 Making the patch disappear once it is pushed out is not possible, the commit
258 the patches the way they would look like if your latest patch series was to be
262 as a patch to the list with a commit message explaining the technical
272 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
283 reading about http://oss-security.openwall.org/wiki/mailing-lists/distros
287 Co-posting changes to user space components
304   [PATCH net-next 0/3] net: some feature cover letter
305    └─ [PATCH net-next 1/3] net: some feature prep
306    └─ [PATCH net-next 2/3] net: some feature do it
307    └─ [PATCH net-next 3/3] selftest: net: some feature
309   [PATCH iproute2-next] ip: add support for some feature
315 -----------------
317 Attention to detail is important.  Re-read your own work as if you were the
319 the ``--strict`` flag.  But do not be mindlessly robotic in doing so.
321 end-user visible symptom, the underlying reason as to why it happens,
324 mis-indent function arguments that span multiple lines.  If it is your
325 first patch, mail it to yourself so you can test apply it to an
329 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
336 your patch is targeting. Assuming that you use git, use the prefix
339   git format-patch --subject-prefix='PATCH net-next' start..finish
341 Use ``net`` instead of ``net-next`` (always lower case) in the above for
342 bug-fix ``net`` content.
347 Put yourself in the shoes of the reviewer. Each patch is read separately
355 with better review coverage. Re-posting large series also increases the mailing
380 Using device-managed and cleanup.h constructs
383 Netdev remains skeptical about promises of all "auto-cleanup" APIs,
394 Similar guidance applies to declaring variables mid-function.
396 Clean-up patches
399 Netdev discourages patches which perform simple clean-ups, which are not in
404 * Conversions to device-managed APIs (``devm_`` helpers)
407 at a greater cost than the value of such clean-ups.
419 Make sure you address all the feedback in your new posting. Do not post a new
428 -------
436 Ideally you will have done run-time testing specific to your change,
437 and the patch series contains a set of kernel selftest for
441 tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``.
449 https://github.com/linux-netdev/nipa/tree/master/tests
462 Mock-ups and tests based on ``netdevsim`` are strongly encouraged when
474 -----------------
482 their comments impeding or derailing the patch flow.
484 Less experienced reviewers are highly encouraged to do more in-depth
489 -----------------------