Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.
Carlos O'Donell <[email protected]> Wed, 24 May 2023 10:12:52 -0400
| Newsgroups | org.linuxfoundation.lists.cti-tac |
|---|---|
| Organization | Red Hat |
| Message-ID | <[email protected]> |
On 5/24/23 09:43, Siddhesh Poyarekar wrote: > On 2023-05-24 08:44, Carlos O'Donell wrote: >> Likewise, I do post-commit review using the per-commit emails. >> >> Even if we had an advanced process to review and merge code that >> process still needs a belt-and-suspenders review from senior >> maintainers, and I do that by reviewing and often responding to the >> per-commit emails to loop in the people that committed the code. >> >> The question for me is "What is lower cost?" >> >> (a) Walking the git commit history, making a note of where I >> stopped and started, and then writing net new emails when I see >> something that needs correctly. (b) Reviewing an mbox, deleting as >> required, and reply-all when I see something that needs review. >> >> I like the per-commit emails because it lets me have some >> post-commit discussions easily e.g. (b). > > Couldn't you use patchwork for this, filtering on Committed state? > If we have 100% coverage (sending non-matching commits to the ML will > achieve that), you would be able to look through committed patches > and then start the conversation in the patch thread instead of a > separate one through glibc-cvs. Is 100% coverage an achievable and timely goal? :-) I think that Patchwork *could* meet this need but isn't quite there yet. > If noting where you stopped/started is cumbersome then you could add > another Audited terminal state in patchwork to track that. That would need to be a per-reviewer state that doesn't exist today in patchwork. The Audited terminal state would be global, and Joseph and I notice different things in our reviews and apply different criteria for calling out a patch that needs follow up work or review. In summary: - Post-commit review facilitation for projects continues to be a value-add step in the maintainer process and is currently mbox-based. - The bar for post-commit review today is an mbox review-style process and a replacement needs to handle multiple reviewers walking the queue at different rates and applying different criteria to review (tag-based scheme?) -- Cheers, Carlos.