public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: libc-alpha <libc-alpha@sourceware.org>
Subject: Monday Patch Queue Review update (2024-02-05)
Date: Mon, 5 Feb 2024 10:03:02 -0500	[thread overview]
Message-ID: <06f2c95a-ce0b-46fa-c89d-b34a2363db58@redhat.com> (raw)

Most recent meeting status is always here:
https://sourceware.org/glibc/wiki/PatchworkReviewMeetings#Update

Meeting: 2024-02-05 @ 0900h EST5EDT

Video/Audio: https://bbb.linuxfoundation.org/room/adm-alk-1uu-7fu

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.

-- 
Cheers,
Carlos.


                 reply	other threads:[~2024-02-05 15:03 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=06f2c95a-ce0b-46fa-c89d-b34a2363db58@redhat.com \
    --to=carlos@redhat.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).