Patch Review Workflow

The glibc project now uses patchwork to track its patches; its instance is maintained at

Getting a Sourceware Patchwork Account

If you are one of the glibc MAINTAINERS then you need an account on the patchwork instance to maintain state for patches you review or post.

Patch Workflow

Following are the main points of the workflow:

Lifecycle of a patch

The state chart below should give a clear idea of the patch lifecycle. States marked in green are considered final states, i.e. patches in those states will not be visible in the default view.


Patch Workflow Diagram

Notes to developers

When working on your own patches and using patchwork to maintain a list of actionable patches it is often useful to review rejected patches to determine which need more work using a different solution. The problem with this is that reviewing your rejected patches to see which need work gets harder and harder as the list gets longer and longer. There is a need to distinguish, for the developer only, the difference between rejected and dropped versus rejected and needs more work. If you are dropping the patch mark it with the Dropped state, otherwise keep it Rejected if you are going to do more work on the patch. Neither the Dropped or Rejected states are actionable and don't show up for reviewers looking to review patches.

None: Patch Review Workflow (last edited 2015-07-27 21:57:44 by Martin Sebor)