diff options
Diffstat (limited to 'Documentation/process/maintainer-netdev.rst')
| -rw-r--r-- | Documentation/process/maintainer-netdev.rst | 42 |
1 files changed, 35 insertions, 7 deletions
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst index e497729525d5..ec7b9aa2877f 100644 --- a/Documentation/process/maintainer-netdev.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -311,6 +311,14 @@ to the mailing list, e.g.:: Posting as one thread is discouraged because it confuses patchwork (as of patchwork 2.2.2). +Co-posting selftests +~~~~~~~~~~~~~~~~~~~~ + +Selftests should be part of the same series as the code changes. +Specifically for fixes both code change and related test should go into +the same tree (the tests may lack a Fixes tag, which is expected). +Mixing code changes and test changes in a single commit is discouraged. + Preparing changes ----------------- @@ -355,6 +363,18 @@ just do it. As a result, a sequence of smaller series gets merged quicker and with better review coverage. Re-posting large series also increases the mailing list traffic. +Limit patches outstanding on mailing list +----------------------------------------- + +Avoid having more than 15 patches, across all series, outstanding for +review on the mailing list for a single tree. In other words, a maximum of +15 patches under review on net, and a maximum of 15 patches under review on +net-next. + +This limit is intended to focus developer effort on testing patches before +upstream review. Aiding the quality of upstream submissions, and easing the +load on reviewers. + .. _rcs: Local variable ordering ("reverse xmas tree", "RCS") @@ -399,7 +419,7 @@ Clean-up patches Netdev discourages patches which perform simple clean-ups, which are not in the context of other work. For example: -* Addressing ``checkpatch.pl`` warnings +* Addressing ``checkpatch.pl``, and other trivial coding style warnings * Addressing :ref:`Local variable ordering<rcs>` issues * Conversions to device-managed APIs (``devm_`` helpers) @@ -459,8 +479,14 @@ netdevsim ``netdevsim`` is a test driver which can be used to exercise driver configuration APIs without requiring capable hardware. -Mock-ups and tests based on ``netdevsim`` are strongly encouraged when -adding new APIs, but ``netdevsim`` in itself is **not** considered +Mock-ups and tests based on ``netdevsim`` are encouraged when +adding new APIs with complex logic in the stack. The tests should +be written so that they can run both against ``netdevsim`` and a real +device (see ``tools/testing/selftests/drivers/net/README.rst``). +``netdevsim``-only tests should focus on testing corner cases +and failure paths in the core which are hard to exercise with a real driver. + +``netdevsim`` in itself is **not** considered a use case/user. You must also implement the new APIs in a real driver. We give no guarantees that ``netdevsim`` won't change in the future @@ -502,7 +528,7 @@ The exact rules a driver must follow to acquire the ``Supported`` status: status will be withdrawn. 5. Test failures due to bugs either in the driver or the test itself, - or lack of support for the feature the test is targgeting are + or lack of support for the feature the test is targeting are *not* a basis for losing the ``Supported`` status. netdev CI will maintain an official page of supported devices, listing their @@ -525,10 +551,12 @@ helpful tips please see :ref:`development_advancedtopics_reviews`. It's safe to assume that netdev maintainers know the community and the level of expertise of the reviewers. The reviewers should not be concerned about -their comments impeding or derailing the patch flow. +their comments impeding or derailing the patch flow. A Reviewed-by tag +is understood to mean "I have reviewed this code to the best of my ability" +rather than "I can attest this code is correct". -Less experienced reviewers are highly encouraged to do more in-depth -review of submissions and not focus exclusively on trivial or subjective +Reviewers are highly encouraged to do more in-depth review of submissions +and not focus exclusively on process issues, trivial or subjective matters like code formatting, tags etc. Testimonials / feedback |