[PATCH 01/20] dlls/kernel32/tests/heap.c: enable compilation with long types

[Eric Pouech]

Le 08/03/2022 à 18:27, Francois Gouget a écrit :
> Hi,
>
> My understanding is that these patches are pretty much independent from
> each other. If so it may help a bit to not send them as a patch series,
> that is without the partX/total numbering. It could still be a thread
> for the sake of the mailing list though I don't know if that's easy to
> achieve.

Hi François,


most of them are independent yes, but not always

anyway, it's possible to send in smaller independent series (that's not 
too complicated to do)

(eg looking at what I've sent this morning: except the 3 patches for 
user32/tests (which are currently bound [*]), all the other ones could 
have been sent as a single mail)


but, kernel32/tests ain't over yet (need at least one more shot 
tomorrow, hopefully to wrap it all)

and then we have to tackle ntdll/tests which will be even bigger than 
kernel32, and all the d3d modules (DLLs and tests) (Henri's in charge of 
those)


if there are niceness issues, another option is to send less patches 
every day (I tried to keep it ~25 / per day, even it's more ~20 lately)

let me know if you think that's appropriate

A+


[*] this could be even split further, but sending the cleanup part of 
last patch not on a the same run. not sure worth it


>
> The reason is that for patch series it has to concatenate each part with
> all the preceding ones. In this case this means more and more things to
> recompile and thus increasingly long tasks as it progresses through the
> series.
>
> That said, for a series like this, most of the time is spent running the
> tests on Windows so it would only help a little bit. That means if not
> making a patch series is not practical it's ok not to.
>
> There's no need to resend the already sent patches of course.
>
>
> Also there was a question about job priority the other day on the
> mailing list. Notice that this job got a higher niceness that regular
> mailing list patches: 6 instead of 5. That's because one of its tasks
> had a long timeout. That mechanism still leaves a lot of room for
> improvement though.
>