Patch Triage

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

...