I took a look at the "sage -t" in "test-long (src/sage[a-f]*)" of a few recent PRs (going back to June), and it looks to me like they all used the same random seed: 286735480429121101562228604801325644303. Where are you seeing a different seed?
On Tuesday, August 26, 2025 at 11:28:15 PM UTC-4 Vincent Macri wrote: > > - 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/2950dc35-d7ec-4843-859a-a9e4c80cb411n%40googlegroups.com.
