The glibc project now uses patchwork to track its patches; its instance is maintained at http://patchwork.sourceware.org. If you are one of the glibc MAINTAINERS the you need an account on the patchwork instance to maintain state for patches you review or post. Get in touch with either SiddheshPoyarekar or CarlosODonell to get added to the maintainers list on patchwork.
Following are the main points of the workflow:
- The subject line of the email that includes the patch must accurately reflects its content. the subject line is what appears automatically on patchwork and having an ambiguous or inaccurate subject line will only result in your patch being lost in the noise
A reviewer may pick up a patch by delegating it to themselves by following the link to the patch and changing the Delegate to value to their patchwork username. Do not change the status of the patch since it will then disappear from your default view. The patch would still be view-able in a list by modifying the Filters on the list.
- The following states may be used once the patch has reached a resolution or is being actively worked on by the submitter and one or more reviewers:
New - Nobody has reviewed it yet. This is the default status.
Under Review - Someone is looking at the patch. One may alternatively use the Delegate to field to indicate that they are interested in reviewing the patch
RFC - Use this to mark patches that aren't meant to be included as is and are posted as a proof of concept or just to solicit comments on the approach
Accepted - There is consensus for this change.
Rejected - There is consensus that it's a bad idea.
Change Requested - Reviewed and needs rework.
Committed - The change has been committed.
When the status of a patch is Change Requested, a submitter may post an updated version of the patch and mark the older version as Superseded.
- The submitter is still responsible for pinging the patch regularly if there have been no responses
- Once review is done and the patch is pushed, the committer of the patch is responsible for changing the status of the patch.
Lifecycle of a patch
New patch submitted: New
A reviewer picks up the patch for review: Under Review (Note that the reviewer may also just use the Delegate to field so that the patch remains visible to other potential reviewers)
Reviewer thinks patch is OK: Accepted
Reviewer thinks patch is OK, but needs another opinion: New so that the patch becomes visible in the queue again
Reviewer thinks patch is OK, but another reviewer disagrees: Under Review
Reviewer thinks patch is not OK for glibc: Rejected
Reviewer thinks patch needs changes: Change Requested
Patch committed: Committed
Submitter has posted an updated patch, then the old patch status: Superseded
Any maintainer thinks that the posted patch is an RFC and not an actual patch: RFC
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.