Lines Matching +full:domain +full:- +full:idle +full:- +full:state
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.
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
109 -------------------
121 The "State" field will tell you exactly where things are at with your
125 Patch state Description
129 the exact co-maintainer handling patchwork at the time)
131 usually set automatically by the pw-bot
139 sub-maintainer, who will send it on to the networking trees;
141 will usually remain in this state, whether the sub-maintainer
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
154 the value of ``Message-ID`` to the URL above.
160 state directly in patchwork. Patchwork doesn't expose much information
161 about the history of the state of patches, therefore having multiple
162 people update the state leads to confusion.
169 pw-bot: changes-requested
176 completely. Maintainers will classify and update the state of the patches
187 https://netdev.bots.linux.dev/pw-bot.html
199 is no longer active in patchwork and the thread went idle for more
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
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()
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
329 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
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.
355 with better review coverage. Re-posting large series also increases the mailing
378 in the domain of netdev is in the preferred format.
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.
428 -------
436 Ideally you will have done run-time testing specific to your change,
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 -----------------
484 Less experienced reviewers are highly encouraged to do more in-depth
489 -----------------------