Re: Next steps from GTI TAC meeting on 2023-03-08 - Evaluate cost of glibc migration.

On 5/22/23 06:11, Joel Brobecker wrote:
>>> * Sending per-commit email to mailing lists -- this seems like a vestigial
>>>   feature from the pre-git past. Does it really serve any purpose? I am
>>>   fighting to kill a similar feature used on the kernel.org side, because I do
>>>   not see any remaining legitimate use for it -- it just creates a lot of mail
>>>   traffic that nobody really reviews.
>>
>> I think it's extremely useful to have those messages for watching out for 
>> commits that shouldn't have gone in or went in in an unintended form (this 
>> is for human-determined "shouldn't" or "unintended" - not anything 
>> expected to be covered by automated checks).  And also to have a message 
>> ready-made to reply to when something was committed without being posted 
>> to the mailing list.
> 
> I strongly agree as well.
> 

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).

-- 
Cheers,
Carlos.