[LTP] LTP old API conversion

[Petr Vorel]

Hi Andrea,

[ Cc others who were on LTP meeting + Sebastian who might be interested ]

> Hi all,

> so we still have ~200 patches to refactor and to move from old LTP API into
> the new LTP API. That would be really useful for tests maintenance and long
> term supports, such as the `runtest` removal and replacement with a smarter
> tests filtering/grouping.

> This is a tedious task that requires a huge amount of work and in the past
> years we managed to convert hundreds of tests by hand, each one requiring
> multiple reviews iterations.

> It was overwhelming not only for developers, but also for reviewers who
> were stucked by reviewing new patches + tests rewriting.

> In 2026 we have the chance to accelerate this transition from old API to
> new API using LLMs and, as we discussed in the yesterday LTP after release
> meeting, we might be in the right way to start doing it (at least for
> smaller tests).

> I created a set of configurations and skills in my personal repo which can
> be used to start this process: https://github.com/acerv/agents-config.
> It's maily tested using Claude Code, since it's the model which perform
> the best (at the moment), but any other model can be used.

> I experimented with a list of tests that can be obtained with the following
> command:

> wc -l $(grep -R '"test\.h"' --include="*.c" testcases/kernel/ | cut -d: -f1) | sort -g

wc -l $(grep -R '"test\.h"' --include="*.c" testcases/ | cut -d: -f1) | sort -g

Otherwise you miss 12 old API tests.

> .. and tests conversion for tests which are smaller than 200 lines of code
> requires minimal (if no) edit. I will continue to adapt the ltp-convert skill
> in order to tweak and to improve this process for bigger tests.

> ~~ Said so..

> .. since this process seems to be quite straight forward, and with the usage
> of LLM we could easily generate hundreds of patches per month, we don't really
> want to flood the ML with garbage and to overwhelm who's involved into
> maintenance review.

> How we should organize this job?
> Should we set a maximum amount of tests refactoring per month?
> How do we organize these patches? (i.e. with blocks of patches)

I'd vote for limiting patchsets to max tests in a single directory.
Why? Smaller patchset is easier to review. And if just some of the commits are
accepted then fewer commits need to be rebased.

Kind regards,
Petr

> Kind regards,