Patch Triage
I propose that we add a new meeting to https://www.yoctoproject.org/public-virtual-meetings/, similar to the Bug Triage meeting but to review incoming patches. The patch queue is long and whilst we talk about how patches-on-list means anyone can perform drive-by review, there’s no way to know if someone has actually reviewed a patch and mentally said “this looks good”, or if several people have seen a patch and been sceptical but not actually posted their thoughts. This proposal aims to counter that problem.
We have a patchwork instance at patchwork.yoctoproject.org which has the ability to track patches, their state, and assign them to a specific person. This is the bare minimum of a patch triage process, we just need to use it. I admit that what I’m proposing here is inspired by the glibc project process (sourceware.org/glibc/wiki/PatchworkReviewMeetings), because I learnt about their process whilst attending the GNU Cauldron conference.
As we have a fairly constant stream of patches, I expect these triage meetings should be done twice weekly, to allow for rapid feedback and review cycles. Each meeting would be an hour long: the first half spent quickly reviewing as much of the patch queue as possible with any discussion postponed until the second half. This means the attendees can hopefully work through a large number of patches quickly before circling back on the more interesting patches. Any patches which result in a bigger discussion or have open questions should likely be discusseed in the Engineering Sync, where the attendence will be larger. As patchwork is primarily a read-only system (apart from status and delegation), a wiki page will be needed to keep minutes and notes. I propose the process to be as follows:
1. Obtain last patch ID reviewed from the meeting minutes
2. Iterate through the patches since the last patch reviewed, oldest first, and review. 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.
3. Discuss any patches marked a Needs Further Review, and any other patches that the group wish to discuss.
4. Review the state of all patches that have been delegated but not yet resolved.
5. Note down in the minutes the last patch ID reviewed, for the next meeting.
As a straw-man proposal, I suggest Monday and Thursday for the calls. The hour slot immedatiately after bug triage?
