Hello Andres,
I'm doubtful that tracking development branches of LLVM is a good investment. Their development model is to do changes in-tree much more than we do. Adjusting to API changes the moment they're made will often end up with further changes to the same / related lines. Once they open the relevant release-NN branch, it's a different story. Maybe it'd make sense to disable --with-llvm on seawasp> and have ppppppa separate animal that tracks the newest release branch?
The point of seawasp is somehow to have an early warning of upcoming changes, especially the --with-llvm part. LLVM indeed is a moving target, but they very rarely back down on their API changes… As pg version are expected to run for 5 years, they will encounter newer compiler versions, so being as ready as possible seems worthwhile.
ISTM that there is no actual need to fix LLVM breakage on the spot, but I think it is pertinent to be ok near release time. This is why there is a "EXPERIMENTAL" marker in the system description. There can be some noise when LLVM development version is broken, this has happened in the past with seawasp (llvm) and moonjelly (gcc), but not often.
About tracking releases: this means more setups and runs and updates, and as I think they do care about compatibility *within* a release we would not see breakages so it would not be very useful, and we would only get the actual breakages at LLVM release time, which may be much later.
For these reasons, I'm inclined to let seawasp as it is. -- Fabien.
