On 5/20/2026 9:05 AM, Philippe Mathieu-Daudé wrote:
> On 20/5/26 15:09, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé <[email protected]> writes:
>>
>>> On 20/5/26 14:57, Philippe Mathieu-Daudé wrote:
>>>> On 20/5/26 14:52, Markus Armbruster wrote:
>>>>> Philippe Mathieu-Daudé <[email protected]> writes:
>>>>>
>>>>>> Fixes: 812b31d3f91 ("configs: rename default-configs to configs
>>>>>> and reorganise")
>>>>>> Signed-off-by: Philippe Mathieu-Daudé <[email protected]>
>>>>>> ---
>>>>>>    MAINTAINERS | 2 +-
>>>>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>>> index b75f3222f2f..2a4d124fb3c 100644
>>>>>> --- a/MAINTAINERS
>>>>>> +++ b/MAINTAINERS
>>>>>> @@ -256,7 +256,7 @@ X: target/hexagon/gen_idef_parser_funcs.py
>>>>>>    F: linux-user/hexagon/
>>>>>>    F: tests/tcg/hexagon/
>>>>>>    F: disas/hexagon.c
>>>>>> -F: configs/targets/hexagon-linux-user/default.mak
>>>>>> +F: configs/targets/hexagon-linux-user.mak
>>>>>>    F: docker/dockerfiles/debian-hexagon-cross.docker
>>>>>
>>>>> This one's wrong, too.
>>>> Already fixed in Alex's tree:
>>>> https://lore.kernel.org/qemu-devel/20260518102222.80735-2-
>>>> [email protected]/
>>>> Pierrick suggested to repost patch dependencies already queued in
>>>> maintainer tree when posting series; while this seem counter
>>>> productive it could indeed have saved us time.
>>>>
>>>>> I have an unsent patch fixing both.  In fact, I have an unsent series
>>>>> fixing *all* F: patterns that don't resolve to any file.
>>>
>>> I looked for your series without success, then realized you mentioned
>>> it is "unsent". This patch is still valid then.
>>
>> Yes.
>>
>>>                                                  Why mention unsent
>>> work?
>>
>> To avoid duplicated work.
> 
> I'm not sure this thread is making sense o_O
> 
> Let's try to figure what you meant here. I'm not racing to get
> this patch in nor enjoying duplicating work, but this is the
> mailing list rules (due to the intrinsic email workflow latency,
> not to mention subscriber processing their INBOX in FIFO mode).
> 
> See for example last week at least 3 developers fixed the same
> GCC warning issue. Generically, how could we improve that?
>

Ideally, by merging such fixes faster (in one hour, not N days).
More realistically, having a daily CI job that tests latest (stable)
version of compilers before they hit stable distros. This way, all build
issues/warnings would never impact anyone.

For some bugs, some duplication is inevitable, but it should 99% of
those easy build fixes.

For the rest, sending "unsent" work seems like an easy fix :).

Regards,
Pierrick

Reply via email to