patchwork triage process

patchwork triage process

[Kees Cook]

Hi,

Here's my proposal[1] for handling the patchwork patch states:

New: No activity yet.
 - Move to "Under Review" (possibly with a delegate assigned to do the review).
 - Move to "Superseded" if a newer version of the same patch has been sent
   (the patchwork-bot usually does this automatically).

Under Review: Reviewers need to give feedback on the patch.
 - Move to "Changes Requested" if a new version of the patch is needed
   after review feedback.
 - Move to "Handled Elsewhere" if a non-linux-hardening tree says they are
   applying the patch.
 - Move to "Queued" if a linux-hardening tree applies the patch.
 - Move to "Superseded" if a newer version of the same patch has been sent
   (the patchwork-bot usually does this automatically).
 - In rare cases, a patch can be moved to "Rejected", but that is uncommon,
   as normally review feedback is expected to be acted on.

Handled Elsewhere: Going via another tree, but not yet in linux-next.
 - Move to "Awaiting Upstream" once a patch appears in linux-next (the
   patchwork-bot usually does this automatically).

Queued: Going via a linux-hardening tree, but not yet in linux-next.
 - Move to "Awaiting Upstream" once a patch appears in linux-next (the
   patchwork-bot usually does this automatically).

Awaiting Upstream: In linux-next, but not yet in Linus's tree.
 - Move to "Mainlined" once a patch appears in Linus's tree (the
   patchwork-bot usually does this automatically).

Mainlined: Done! In Linus's tree.


This should let us see each given state, and makes a distinction between
things going via one of the KSPP trees (Queued) vs a different subsystem
(Handled Elsewhere). i.e. we can check for stalled patches by getting
a list of all the "Handled Elsewhere" patches, since any that appeared
in -next should have moved on to "Awaiting Upstream", etc.

Thoughts?

-Kees


[1] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project/Patch_Tracking

-- 
Kees Cook