Commit ee8ab74a authored by Jakub Kicinski's avatar Jakub Kicinski Committed by David S. Miller
Browse files

docs: netdev: document patchwork patch states 



The patchwork states are largely self-explanatory but small
ambiguities may still come up. Document how we interpret
the states in networking.

Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 719c5e37

Documentation/process/maintainer-netdev.rst

+31 −1
Original line number Diff line number Diff line
@@ -120,7 +120,37 @@ queue for netdev: 
  https://patchwork.kernel.org/project/netdevbpf/list/



The "State" field will tell you exactly where things are at with your

patch. Patches are indexed by the ``Message-ID`` header of the emails

patch:



================== =============================================================

Patch state        Description

================== =============================================================

New, Under review  pending review, patch is in the maintainer’s queue for

                   review; the two states are used interchangeably (depending on

                   the exact co-maintainer handling patchwork at the time)

Accepted           patch was applied to the appropriate networking tree, this is

                   usually set automatically by the pw-bot

Needs ACK          waiting for an ack from an area expert or testing

Changes requested  patch has not passed the review, new revision is expected

                   with appropriate code and commit message changes

Rejected           patch has been rejected and new revision is not expected

Not applicable     patch is expected to be applied outside of the networking

                   subsystem

Awaiting upstream  patch should be reviewed and handled by appropriate

                   sub-maintainer, who will send it on to the networking trees;

                   patches set to ``Awaiting upstream`` in netdev's patchwork

                   will usually remain in this state, whether the sub-maintainer

                   requested changes, accepted or rejected the patch

Deferred           patch needs to be reposted later, usually due to dependency

                   or because it was posted for a closed tree

Superseded         new version of the patch was posted, usually set by the

                   pw-bot

RFC                not to be applied, usually not in maintainer’s review queue,

                   pw-bot can automatically set patches to this state based

                   on subject tags

================== =============================================================



Patches are indexed by the ``Message-ID`` header of the emails

which carried them so if you have trouble finding your patch append

the value of ``Message-ID`` to the URL above.