[PATCH] D142473: [UTC] Add --version argument

Tue Jan 24 09:27:57 PST 2023

nikic added a comment.

In D142473#4077309 <https://reviews.llvm.org/D142473#4077309>, @asb wrote:

> My initial reaction is that this is a nice solution to the problem - thank you! The main practical challenge I see is the the one you suggest in the summary - that it might not be easy to decide when it's "worth" introducing a new version, and there might be pressure in practice to group together multiple changes at once.

I think from a maintenance perspective, it actually makes little difference whether these are in one version or in three. I believe the implementation of each change is essentially orthogonal, and would not become substantially simpler (or simpler at all?) when combined in one version. So this would mostly be a cosmetic question for me.

Maybe worth mentioning that I don't think every change to UTC output needs a version bump: Only those that could cause significant churn. For example, I don't think we should bump the version every time we add support for recognizing some new metadata, or other changes that don't affect many tests.

In D142473#4077336 <https://reviews.llvm.org/D142473#4077336>, @nhaehnle wrote:

> - In the past, I have on occasion made commits that only re-run UTC on existing tests, without making any other changes, and without posting them for review.

Yes, this isn't an unusual thing to do. Generally if you either hit a test that hasn't been converted yet, or there have been some substantial changes to instruction names. It's mostly a question of scale. At this point, with most tests (that I care about) using UTC, this is something that one has to do only occasionally. With changes like "enable --function-signature by default" you have to do that for literally every single test you touch.

Marginally increased maintenance costs in UTC are something that affects only few people and few changes, while test churn affects everyone. The "regenerate test checks, see that some need a regenerated baseline, checkout main, rebuild, regenerate baseline, push the change, rebase, find out that somebody 'improved' an ADT header in the meantime, wait 15 minutes for the build to finish, go back to your actual work" cycle adds non-trivial overhead to development, and test management is already a big time-sink as it is.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142473/new/

https://reviews.llvm.org/D142473