Patch Triage: Difference between revisions

From Yocto Project
Jump to navigationJump to search
No edit summary
No edit summary
 
Line 22: Line 22:
=== Patch State Summary ===
=== Patch State Summary ===


[[File:patchworkflow.png]]
{{#mermaid:flowchart TD
    Start(Start) --> New[New]
 
    New-- RFC, no further action needed -->RFC(Request for Comments)
 
    New-- Patch will not be accepted -->Rejected(Rejected)
 
    New-- Patch looks okay,<br>delegate commits to review -->UR[Under Review]
 
    UR-- Patch good,<br>can be merged -->Accepted(Accepted)
 
    UR-- Patch needs work,<br>feedback sent -->Change[Change Requested]
 
    Change-- Improved patch posted -->Superseded(Superseded)
 
    UR-- Patch needs further discussion -->New
 
    New-- Submitter has sent<br>an improved patch -->Superseded
}}


* New: Nobody has reviewed it yet
* New: Nobody has reviewed it yet

Latest revision as of 10:19, 13 October 2023

The Yocto Project community is experimenting with a regular patchwork triage meeting; to triage, review, and assign incoming patches.

Everyone is welcome to attend, the call is held on Thursdays at 08:30 - 09:30 PST (the hour after the Bug Triage call). Other meetings may be added to cater for other timezones or if there are more patches than can be triaged.

The focus of the meeting is to triage new patches in patchwork: https://patchwork.yoctoproject.org/project/oe-core/list/

Process

This process is inspired by the process the glibc project use.

  1. Obtain last patch ID reviewed from the minutes
  2. Iterate through the patches since the last patch reviewed, oldest first. Quickly review as a group and assign a delegate and provisional status:
    • Looks Good: move to Under Review status. Will be incorporated into a staging branch by the delegate so that if it fails testing the status can be changed.
    • Looks Bad: move to Rejected status. Note the feedback in the minutes, the delegate is responsible for responding on the list with this feedback.
    • Needs Work (quick): move to Action Required. Note the feedback in the minutes, the delegate is responsible for responding on the list with this feedback.
    • Needs Further Review. Move to Action Required. Note this choice in the minutes, and either discuss later in the call or in the Engineering Sync. It is the responsiblity of the delegate to have this discussion.
  1. Discuss any patches marked a Needs Further Review, and any other patches that the group wish to discuss.
  2. Review the state of all patches that have been delegated but not yet resolved.
  3. Note down in the minutes the last patch ID reviewed, for the next meeting.


Patch State Summary

  • New: Nobody has reviewed it yet
  • Under Review: The patch is under review and testing. Change the delegate to the reviewer.
  • Accepted: There is consensus for merging this patch.
  • Rejected: There is consensus for not merging this patch.
  • RFC: The patch is a Request for Comments to solicit feedback and doesn't need to be tracked further.
  • Change Requested: The patch has been reviewed and needs further work.
  • Superseded - A newer version of the patch exists.
  • Deferred - Review of this patch is waiting for another event to happen.

TODO There is ambiguity around the "Accepted" state. Should this indicate a patch which is ready to be merged, or only for patches that have already been merged? Glibc has a "committed" state to handle this.

TODO Now thinking Under Review until merged (accepted) or rejected (rejected).

Minutes

2023-10-12

...