Re: [boost] The Future of Boost - CI
Vinnie, First of all, let me thank you for taking the time to write all this up, and put into words, probably what we've all been thinking!
Continuous Integration
CI is wonderful, and horrible! The main issues I see are that: a) It needs continual maintenance, as the host runner upgrades/changes the systems they support. b) Stuff breaks without notice because we never know when the hosting CI service will change something. c) Knowledge of fairly obscure scripting is required to make the most of it. Strictly IMO, the issues that Robert Ramey was complaining about in CI recently were due to the above rather than anything wrong with the concept, or indeed Boost. So... in my ideal world Boost CI would look something like this: * The library author does nothing more than list (maybe in json or something similarly popular) the systems they want to test on - and these would be abstract Boost-wide names like "core", "bleeding edge", "legacy-msvc" etc. Exactly what these map to would be defined elsewhere. But the point is that now, library authors would almots never need to update their CI script *and* all Boost libraries get tested on the same "core" which would also form our release criteria. * Updates and changes to CI would be announced here first, if in doubt new compilers *might* go in "bleeding-edge" first and "core" a release later. Machine time could well be donated by volunteers and perhaps replace the current test/status matrix, which is fine, but requires you to go off seeking for results, which may or may not have cycled yet. Plus that matrix relies on a "build the whole of Boost" approach which increasingly simply does not scale. I'm hoping that approach might even allow us to diversify our testing somewhat - to pick a random example - Intel used to be very generous in proving us with compiler-licences to test with, but these are sadly incompatible with CI, but I suspect they would be compatible with individual testers acting as CI hosts though. I'm sure there are other examples: MSVC/GCC/Clang are not the only games in town. Best, John.
participants (1)
-
John Maddock