public inbox for
 help / color / mirror / Atom feed
* Monday Patch Queue Review update (2024-02-05)
@ 2024-02-05 15:03 Carlos O'Donell
  0 siblings, 0 replies; only message in thread
From: Carlos O'Donell @ 2024-02-05 15:03 UTC (permalink / raw)
  To: libc-alpha

Most recent meeting status is always here:

Meeting: 2024-02-05 @ 0900h EST5EDT


IRC: #glibc on OFTC.

Review new patches and restart review at the top.

- State NEW delegate NOBODY at 473 patches.
- Carlos's SLI at 265 days average patch age in queue and 126812 accumulated patch days.
- Carlos: Starting this meeting a bit different than usual, and I'd like to talk about what we are doing right and what we might change in the patch review process.
- Maxim: From the point of view of CI, and what I monitor at Linaro, and one thing which is taking time and difficult for us to do is notification of patch authors. At the moment we have several challenges. We send out a single notification only to the patch author without copying anyone else. If you copy too many people it will create a lot of noise, every single configuration will want to send that email. For example aarch64 can know it has sent notification for the patch, but not if another notification has or hasn't sent that. For patchwork it is much easier to send out nicely formatted email at the right cadence to the mailing list which may include a bigger audience. Sending out digests would be really useful. At most we get 1-2 emails for patch review of patchwork can handle the patch.
- Carlos: Could we write a bot for this?
- Maxim: I understand how we use the bot to use local email servers. How do we send the summaries?
- Carlos: The bot uses sqlite3 and walks the data with id and date and it is possible.
- Carlos: Your idea is to avoid high noise right?
- Maxim: I would like Gerritt but I don't expect we can deploy that in the GNU Toolchain.
- Carlos: Right.
- Florian: Joseph made a comment and noted that none of the alternatives is compelling enough to make a switch from the email based workflows.
- Maxim: The lack of authority to assign work to people is a flaw? It would be good to have volunteers which would like to review patches.
- Carlos: We do have some pool, for example DJ and Arjun are two people from Red Hat that have volunteered to review patches.
- Maxim: I bet we can get 10-20 people on this list for review.
- Maxim: My thesis is that it will be beneficial to the community and the reviewer.
- Florian: Some reviews fail to catch locally incorrect issues or globally incorrect issues (deployment).
- Florian: So even technically skilled reviews fail to catch issues. So the skill of the reviewer should not be a limiting or high bar factor to reviewing patches.
- Carlos: Yes, we can do this.
- Florian: Could we make this pull? So the developer just pulls a patch and reviews it.
- Maxim: We have upstream time set aside at Linaro to do patch review.
- Adhemerval: A workflow where we define features per releas and review them as point release features. There is no defined plan and that frustrates some developers and is rushed at the end of the release.
- Carlos: What about a 1 month boundary? Deliver the planning by 1 month boundaries.
- Adhemerval: Yes. By having a monthly plan we can more easily post-pone features.
- Carlos: Will the more junior reviewers need mentorship from senior people?
- Maxim: Yes, we need to setup a web page with mentors for review.
- Szabolcs: I find it tricky to review arbitrary patches. Sometimes it's easy or I have a single comment, and sometimes I need to do more research.
- Maxim: We are not the first ones challenged by this problem. In gerritt we have +1 for looks good, but you need a reviewer to approve.
- Maxim: There is quality for humans and computers. Each should be achieved by different means, largely human review and computer review (pre-commit CI).
- AI: For Maxim to send out an email to create a queue of reviewers.
- AI: For Carlos to send out an email about project planning in glibc.


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2024-02-05 15:03 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-05 15:03 Monday Patch Queue Review update (2024-02-05) Carlos O'Donell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).