Am 06.11.23 um 01:09 schrieb Robert Ramey via Boost:
I doubt that the serialization library is the only one with this issue. Most libraries have passing CI on multiple CI providers and we (Boost devs) work together helping each other in most cases. We have Boost.CI which has templates that are updated when common issues are found so other Boost devs can just C&P that update into their scripts. The sadist part of all this is that even if it did "work" it would still be useless. It's not uncommon for a large and/or complex library to fail one or more tests on one or more compilers due to issues in the compiler itself. These can't be "fixed" in the library. The test matrix shows all the tests x all the environments. One can easily see if any failure is general or isolated to a particular environment. That is true. But I'd consider this one big advantage of Boost that it has workarounds in place for many compiler deficits such that Boost works in more environments and even with compiler bugs than other projects. The output of the CI is very user unfriendly. How so? It is a nice list with a red or green mark next to a short description of the configuration (e.g. OS, compiler version, CXX standard) and has the full logs The test matrix on the other hand is missing easy access to logs and feedback on changes not yet merged to develop but merging without extensive tests risks breaking downstream libraries. A useful observation. The problem is that the current CI tests the development branch of one's library agains the develop branch of all the other libraries. So now my library looks like it "works" but when (and only when) it could fail when run against all master branches. So the testing shows pass when it actually fails when shipped with the master. Note that as we speak the test matrix for the master branch isn't working so it seems we never test the software which is actually being shipped. The same CI runs against master branch for pushes or merges of/to master I tend to actually open a a PR from develop to master to verify nothing will be broken on master after the merge. I see the merit in this observation. Personally, on my own machine, I test my development or feature branch agains the master branch of all the other libraries. It's the only way to know that when the changes are merged into the master the software will still work. See above: It is useful but not the only way and limitted in scope (not as many compilers/configurations tested as e.g. the Boost.CI template does)
Then there's the recurring problem that led to this post - people forget to merge to master from time to time. Or simply don't have time to merge. Or the library is no longer actively maintained. Or the commit is left out of master for any other reason, which means users don't receive their bug fixes in a release. Right
I agree here that this is a major issue and maybe the release managers can check (e.g. with Peters script) for that common issue and maybe even initiate merges. I do see a value in having a separate develop and master branch: During release cycles you can continue working on develop while master is frozen for the ongoing release. Besides that it is true that feature branches should be enough and develop could be removed. Alex