Re: [PATCH v2 03/16] tests/Makefile.include: add binary dependency to run-tcg-tests-% rules

["Alex Bennée" <alex.bennee@linaro.org>]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 5/28/2026 11:03 AM, Alex Bennée wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 5/28/2026 3:13 AM, Alex Bennée wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>>>>> On 5/26/2026 11:17 PM, Alex Bennée wrote:
>>>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>>>
>>>> <snip>
>>>>>>
>>>>>> What do you mean? I run check-tcg all the time.
>>>>>>
>>>>>> Which containers fail to build for you? The main cross-compiler one
>>>>>> (debian-all-test-cross) is built all the time.
>> <snip>
>>>>> I'm a bit tired of seeing patches in your subsystems get stuck for
>>>>> weeks, without any proper review, to finally be (re)posted again in a
>>>>> new series, blocked for more weeks, and finally reach upstream one month
>>>>> later or worse. It's truly exhausting for everyone contributing in such
>>>>> places.
>>>>
>>>> What can I say - reviews are welcome. I always list what patches are
>>>> still waiting for review in the cover letter. I should also add for
>>>> testing/next I try to be extra careful that regressions don't slip in
>>>> because keeping the testing sub-system stable is important to support
>>>> things like bisection.
>>>>
>>>
>>> The main issue with your personal workflow, which is "reposting existing
>>> series concatenated in a new single series", is that it adds a lot of
>>> latency. Basically, if one patch fails, or is not reviewed, the whole
>>> thing is blocked. And that is a problem. I don't see what it's supposed
>>> to achieve, since it's halfway between a series, and a PR, without being
>>> one or the other.
>>>
>>> TLDR: the problem is how long things are between receiving reviewed-by,
>>> and being in a pull request in your subsystems.
>>>
>>> For instance, in current series, there are multiple sub series. Some of
>>> them are fully reviewed and ready to go, they can be sent as PR
>>> independently.
>>>
>>> I remember you mentioned several times that you like to have a "single
>>> branch". I have the same workflow, and it absolutely does not prevent to
>>> send multiple PR or series in parallel.
>> 
>> I do split stuff out when it makes sense, but look at testing/next:
>> 
>> e02df7f4810 * testing/next MAINTAINERS: Cover python.docker with Python library section
>> 4fcb3a8c07a * MAINTAINERS: Cover debian-tricore-cross.docker with TriCore section
>> b554638aea6 * MAINTAINERS: Cover debian-xtensa-cross.docker with Xtensa section
>> 8417a661600 * MAINTAINERS: Cover debian-loongarch-cross.docker with LoongArch section
>> 0f57fbac5bc * MAINTAINERS: Fix docker/dockerfiles/debian-hexagon-cross.docker path
>> 
>> Maintainers updates aren't critical to get in now.
>>
>
> The more you wait, the more it might create conflicts. That's basic
> software engineering, and where the term Continuous integration comes
> from. It does not mean "run a GitLab pipeline", it means integrate
> often, *continuously*, with low latency.
>
> There has been concrete examples of why delaying created an issue in the
> past. In the current series, "docker: Remove LegacyKeyValueFormat*"
> basically blocks any other change in concerned files, as soon as it does
> not land. At least those two could have been sent as soon as possible.
>
> If you'd send a PR regularly (at least every week), it would be less a
> problem. Miss the train? get the next one.
>
> If you want a good analogy:
> Problem is that your train is leaving at random time, and it has several
> wagons, which increase the risk of a mechanical failure every time. As a
> result, passengers are stuck waiting.
>
>> f80f388a538 * gitlab: update issue template for binary test cases
>> 4e7de923722 * gitlab: add MacOS 26 job on gitlab runner
>> e0692ad4b23 * gitlab: add initial MacOS 15 on gitlab runner
>> 1299b5aec2f * ci: drop cirrus MacOS build
>> 
>> None of these matter without bellow
>> 
>> dd2db9273be * accel/tcg: move jit thread manipulation into do_tb_phys_invalidate
>> 
>> b60553095bb * tests/Makefile.include: add binary dependency to run-tcg-tests-% rules
>> bcde94b9315 * tests/Makefile.include: fix typo in comment
>> 
>> Why take the chance to break the build when the changes are in service
>> of the wider patch? The more runs through the CI to shake out anything
>> the better.
>> 
>>> If tooling is the limitation, please take a look to those (ugly) scripts
>>> for inspiration. AI can probably rewrite this better than me in 10 min.
>>> With this, sending a series or a PR is a complete no-op for me, I just
>>> wait for CI to run, and send it when ready 2h later.
>> 
>> Tooling isn't the issue - but I'm never going to be doing multiple PRs a
>> week because each one has a degree of latency due to CI coverage.
>>
>
> Sorry, but this sentence doesn't make any sense at all.
> What is the "degree of latency due to CI coverage"?
>
> CI takes less than 2 hours to run, you can run it 4 times within a
> working day. 5 days a week. That's 20 chances to send a PR.
> The only latency is human based, and a way to solve it is to automate.
> Lack of tooling *is* the problem in this situation.
>
> You can't take a lot of pride in automating things with AI, and claim
> it's impossible to automate sending a series of patch and run a CI
> pipeline from it. Use AI if you want, but please apply it everywhere
> it's needed.
>
>>> Saying "people have to accept my tempo" is not acceptable. Fix the
>>> tooling instead.
>> 
>> I think it is fundamentally down to the maintainer what tempo they are
>> happy and able to work at. If you wish to take on responsibility for more
>> areas of the code base then be my guest.
>>
>
> There is a difference between being really busy and just adding latency
> artificially because "I said so". We worked together, so I can make the
> difference between the two.
>
> I would be happy to help maintain any part that needs help. Maintaining
> plugins was a suggestion that came from Richard, and yes, I was open to
> do it for a long time, especially after experimenting weeks of latency
> to see patches get merged, and this several times.
>
> I stepped in for docs because we identified there was a need for it.
> I also talked with you in private to help on linux-user and you
> explicitly asked me to wait, without any specific reason. Now Helge is
> maintaining it and doing an excellent job, I'm really glad he stepped in.
>
> I would be happy to help co-maintain tests/tcg and help this move to
> meson. Unfortunately, you snipped that part without even trying to
> answer to my proposal of helping by making a small proof of concept.
>
> Coming back to your proposal, do you wanna share maintainership on
> tests/tcg/multiarch and tests/tcg?

I'm happy to turn over the maintinership of tests/tcg to you with the
new meson based system.

>
>>>
>>> Regards,
>>> Pierrick
>> 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro