Maybe I'm speaking out of turn from the sidelines, but just curious to ask a leading question...
What is the purpose of the Continuous Integration system?
I notice Travis has not had a green build for nearly 120 days
since Build #603...
I'd guess that makes it harder to identify which "new" commits introduce "new" defects.
It was tough for me trying to categorise the historical failures to understand what might be required to make them green.
For example, lately the usual failure has been just a single job...
macos32x64 squeak.sista.spur.
which last worked 22 days ago in Build #713
but there are other failures in builds that obscure that fact, way back to #603.
Only an exhaustive search through all builds reveals this.
For example, recent Build #748 has macos32x64 squeak.sista.spur as its only failure
but then #750,#751, #752, #753 introduce other failures.
Perhaps a contributing factor is commits being pushed directly to the server Cog branch,
with CI tests only running after they are integrated. I guess that was done to keep the workflow
similar for those moving from subversion to git. However it seems to lose some value of CI
in "preventing" build failures from entering the repository. After a year of using git maybe
this workflow could be reconsidered? Perhaps turn turn on branch protection for administrators
and "force" all commits to the server Cog branch to first pass CI testing?
Of course needing to submit everything via PRs adds workflow overhead, but some workflows might minimise the impact.
So I can't argue whether the benefit is worth it, since I'm not working in the VM every day.
I'm just bumping the status quo to table the question for discussion.
cheers -ben
P.S. Should macos32x64 squeak.sista.spur be fixed, or temporarily removed from the build matrix?
A continually failing build seems to serve no purpose, whereas green builds should be a great help to noticing new failures.