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.