On 11/6/23 1:45 AM, Alexander Grund via Boost wrote:
Am 06.11.23 um 01:09 schrieb Robert Ramey via Boost:
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)
Hmmm - I'm not seeing this. Maybe I'm not doing something right or haven't invested enough time in it. 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.
Right the test matrix only includes tests merged into the development branch.
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)
Right, buts its my only option given the circumstances.
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.
Seems to me it would be easy to make a script which the release manager would run before release which would flag all libraries which have unmerged changes on the development branch dated before the current date. This might resolve the whole issue.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost