* My understanding is that all CI runs now use the same random seed We do use random seeds, and we should.
https://github.com/sagemath/sage/issues/40632 was found because we have a test that generates a random input to a function and 0 is not valid input for that function. For some seeds, like the one used by the CI for one run which found this bug, the test generated 0 as the input value. This is a bug and so I think this demonstrates that we should use random seeds. It was also unrelated to the PR. Perhaps one could run tests for both a fixed and random seed to avoid unrelated failures while still testing random inputs, but doubling the amount of CI tests we run seems somewhat wasteful. 1. Sometimes PRs introduce reproducible build errors on a small subset of systems ... then after some time disable the failing system 2. I think we should not drop support of a system (platform) failing because of bugs introduced by PRs. I think you two are saying two different things (I added emphasis for the difference) and I generally agree with both. If Sage fails to build on a system, especially an old system that has reached end of life (which I think is the case for what Tobias was talking about) I don't think we need to spend time trying to support it. For example, we regularly drop support for old Python versions, but there are surely some systems where newer Python versions aren't available. I think that's fine. Ideally, we would have removed the unsupported systems from CI when we dropped support for the old Python. Better yet would be if the CI knew which versions of those distros we test are supported without us having to update the CI configuration whenever there is a new or EOL Ubuntu/Fedora/whatever. As for bugs, if the system builds Sage and then a test fails after it successfully builds, that's a problem. If Sage builds but has failing tests on say, the most recent Fedora that's something we obviously should not ignore. If it builds and tests fail on an older system, maybe some Ubuntu LTS that's past EOL, I think it's still worth investigating why the failure occurred. Maybe it's relevant to Sage and tells us something, maybe it doesn't. Depending on what test failed and why we evaluate if it's a regression or just a matter of trying to run Sage on a system that is past EOL where a recent enough version of some compiler/library is unavailable. In a perfect world we would track down what specific version of what library is causing the bug and update the build dependencies to not allow that version. In practice I think that might be an unrealistic amount of work for us that provides little practical benefit. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sage-devel/TO1PPFB4708EDB74D2BCBA8BC9B846493B8F738A%40TO1PPFB4708EDB7.CANPRD01.PROD.OUTLOOK.COM.
