Tools and CI Meeting - Date 5/20

[spbrogan]

Weekly meeting to discuss Tools, CI, and codebase construction topics.

Status

Scheduled for 5/20/2024

Agenda

Discuss PR process and make sure process is ready for May 24th (friday)

Groups.io meeting invite:

https://edk2.groups.io/g/devel/viewevent?repeatid=43269&eventid=2159616&calstart=2024-01-08

Microsoft Teams meeting

Join on your computer or mobile app
Click here to join the meeting
Or call in (audio only)
+1 425-616-0754,,330776518# United States, Seattle
Phone Conference ID: 330 776 518#
Find a local number | Reset PIN
Learn More | Meeting options

[spbrogan]

@bcran asked for a status update on edk2-basetools project with focus on moving the C tools to python. Attention @YuweiChen1110 and @mdkinney as I believe this was work you both desired. From the issue list (https://github.com/tianocore/edk2-basetools/issues) it looks like most have not been started. The VFR compiler has PR has not changed since Nov 2023 (tianocore/edk2-basetools#109).

[spbrogan]

Meeting on for 5/20 to discuss PRs

[spbrogan]

Meeting recording has been uploaded to the youtube channel.
https://youtu.be/7IyKNdyBACA

Generated by AI. Be sure to check for accuracy.

Meeting notes:

PR code review process:

Michael presented the updated wiki pages for the new PR code review process and received feedback from Kinney, Sean, John and Rebecca. The main changes are using PRs instead of mailing lists, dropping CC and Reviewed-by tags, and using GitHub features for commenting and suggesting changes.

• Wiki pages update: Michael showed the development process page, the PR tips page, and the commit message format page, and explained how they reflect the new PR code review process.
• Feedback and suggestions: Michael received feedback and suggestions from the others on various aspects of the new process, such as Stuart usage, commenting policy, commit message review, PR template, and code owners file. He agreed to make some changes and left notes for further discussion.
• Deployment plan: Kinney confirmed that the plan is to enable the new process immediately after the stable tag, and asked Michael to share the wiki changes with the community for review. He also mentioned the need to update the patch check tool to drop the CC check.

Stuart usage:

Kinney suggested to make Stuart usage optional and conditional on PR status check failures, rather than mandatory for all contributors. Michael agreed to update the wiki pages accordingly and also mention the limitations of running Stuart locally.

• Stuart usage: Kinney argued that requiring Stuart usage for all contributors might be too burdensome and suggested to make it optional and only necessary if the PR status checks fail. He also wanted to make it clear that running Stuart locally does not cover all the tool chains and OS combinations that CI runs.
• Wiki update: Michael agreed to update the wiki pages to reflect Kinney's suggestion and to link the Stuart page to the PR creation step. He also said he would mention how to look at what is being used in CI to better reproduce the issues locally.

PR tips page:

Michael showed the PR tips page that covers various GitHub features and tools for working with PRs, such as notifications, code suggestions, commit search, and code spaces. He also received some suggestions for adding more information on commenting policy, commit message review, and PR template.

• PR tips page: Michael explained the purpose of the PR tips page, which is to help people who are new to GitHub PRs or want to find a workflow that works for them. He highlighted some key features of the GitHub UI, such as notifications, code suggestions, commit search, and editing in the browser.
• GitHub tools: Michael also showed some other tools that can be used with GitHub PRs, such as GitHub CLI, GitHub code spaces, VS code GitHub PR plugin, and GitHub desktop. He said that all of these tools are cross-platform and can help with different aspects of the PR process, such as creating, reviewing, and merging PRs.
• Suggestions and feedback: Michael received some suggestions and feedback from the others on the PR tips page, such as adding more information on commenting policy, commit message review, and PR template. He agreed to address those suggestions and left notes for them.

Code owners file:

Kinney and Michael discussed the plan for using code owners file to automate reviewer assignment and verification. Kinney proposed to phase in code owners first and then reviewers, and keep maintainers.txt in parallel until everyone is familiar with the new syntax and scope of code owners.

• Code owners file: Kinney and Michael discussed the benefits and challenges of using code owners file to automate reviewer assignment and verification. They agreed that code owners file can help with adding the right reviewers and checking that they have approved the PRs.
• Phasing plan: Kinney proposed to phase in code owners first and then reviewers, and keep maintainers.txt in parallel until everyone is familiar with the new syntax and scope of code owners. He said that the syntax and scope of code owners are different from maintainers.txt and that it might take some time to adjust to them.

Follow-up tasks:

1. Development process wiki: Update the wiki pages with the feedback and suggestions from the meeting (Michael)
2. Patch check tool: Remove the hard error for missing CC tags in the commit messages (Kinney)
3. Code owners file: Create a code owners file that matches the maintainers.txt file and enable it for automatic reviewer assignment (Michael)
4. Reviewers group: Create a GitHub group for reviewers and set up the automation for checking the reviews (Michael)
5. PR template: Create a PR template with three sections: summary, tests performed, and integration instructions (Michael)