Differences between revisions 10 and 11
Revision 10 as of 2014-08-05 14:15:32
Size: 5528
Comment: tweak grammar
Revision 11 as of 2014-08-05 14:17:05
Size: 3355
Comment: fix conflicts due to flaky internet
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
---- /!\ '''Edit conflict - other version:''' ----
Line 3: Line 2:

---- /!\ '''Edit conflict - your version:''' ----
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]] then 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.

---- /!\ '''End of edit conflict''' ----
Line 11: Line 5:

---- /!\ '''Edit conflict - other version:''' ----
Line 20: Line 12:

---- /!\ '''Edit conflict - your version:''' ----
 * 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''' - 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 committing this change.

---- /!\ '''End of edit conflict''' ----
Line 35: Line 16:

---- /!\ '''Edit conflict - other version:''' ----
Line 38: Line 17:

---- /!\ '''Edit conflict - your version:''' ----
 * The submitter is still responsible for pinging the patch regularly if there have been no responses.

---- /!\ '''End of edit conflict''' ----

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 then 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 - 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 committing 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.

glibc-patchwork-workflow.png

None: Patch Review Workflow (last edited 2014-12-04 14:49:26 by CarlosODonell)