Hi Ævar, On Fri, 25 Mar 2022, Ævar Arnfjörð Bjarmason wrote: > A re-roll of my improvements my series to simplify the CI setup a lot > (see diffstat), much of it was dealing with constraints that went away > with Travis et al. This type of work causes me a lot of follow-up work e.g. many merge conflicts in the latest Git for Windows rebases. Perhaps it is worth taking a step back and evaluating the return on this investment in the CI setup. While this can be characterized as a simplification taking the diffstat as proof, one could challenge that the diffstat does not actually measure whether the code is simple or not, it just measures whether there are less lines in the end. If the diffstat was a good measure, then the optimum would be one 0-byte `.c` file (which some C compilers compile without error). Another obvious way to optimize the diffstat would be to remove all code comments. Would I suggest to do either? Of course not. The reduction in code size of this patch series also comes at quite a steep cost: After all, the way Lars and Gábor set things up was already easy to reuse with Azure Pipeline and GitHub Actions. Removing this type of generic, easily-to-adapt code can remove a lot of lines at the expense of making the code less generic and harder to adapt, and leads us directly to CI lock-in. A better approach would be to use the already-generic code and adapt it e.g. to extend to the CirrusCI definition we have. Even if you do not care about extending our FreeBSD coverage, I would like to ask to slow down on refactoring as it is done in this patch series. As indicated in my comment above, these types of refactorings lead to a lot of complications in Git for Windows's processes, which are time-consuming to resolve. I understand your motivation, but if you wouldn't mind taking some time to weigh the criticality of these changes against the overhead incurred for maintainers, it would be appreciated. > I think just removing it is OK, we can always bring it back if needed, > and doing so is actually going to be simpler on top of this since the CI > is now less special, and leans more heavily on the logic of our normal > build process. Removing and re-adding things does take time, though. Again, I think it would be helpful to step back and try to understand the value of this removal versus the projected time it would take (from all involved) to re-add. Besides, given how much is shuffled around in this patch series (e.g. some files in ci/ are removed altogether and their equivalent code is moved into various other places), doubt must be cast on the idea that it would be simple to bring back anything here. Ciao, Johannes
