Re: One test per line, one source per line, etc. etc. etc.

[Carlos O'Donell <carlos@redhat.com>]

On 6/27/21 4:14 PM, Florian Weimer wrote:
> * Carlos O'Donell via Libc-alpha:
> 
>> Do we have consensus for someone to just cleanup all the makefiles
>> to have one source per line, one test per line etc.?
> 
> I think there was some opposition to trailing \ in lists in Makefiles.

In this thread:
https://sourceware.org/pipermail/libc-alpha/2020-December/120667.html

There was no objection, but it was a concrete change, not the general
discussion.

Ah, this is the thread I proposed it:
https://sourceware.org/pipermail/libc-alpha/2020-December/120693.html

DJ was in favor.
Joseph appears to favor LC_COLLATE=C.
Siddhesh suggests tests could be renamed to get more logical orderings.
Carlos clarifies, yes, LC_COLLATE=C, and yes test renaming would help.

There doesn't seem to be any opposition.

I think we have consensus to change all the files in a semi-automatic
refactoring that would help reduce conflicts.

> This:
> 
> routines += \
>   read \
>   write \

This. To reduce conflicts.

> 
> vs:
> 
> routines += \
>   read \
>   write

No objections noted for this that I can find.

> 
>> The more reviews I do, the more this causes my to stumble and have
>> to work through merge issues.
>>
>> If I want to get to 100 patches reviewed per day I think this is going
>> to block me.
> 
> Avoid merge conflicts also needs a custom merger (easier if the data is
> in separate files with a more regular file).

Avoiding *all* conflicts needs a custom merge driver.
 
> Sorting the lists lexicographically avoids conflicts only
> stochastically, for sufficiently long lists.

And we have such lists already so the refactor would reduce conflicts
without much actual work required.

In summary:
- I see no objections to a refactoring across libc to do this.
- I see no objections to trailing \.

The patches would obviously need to go through review, but it seems like
all we need to do is do the work.

-- 
Cheers,
Carlos.