2018-06-07 14:16 GMT+02:00 Jeroen Demeyer <j.deme...@ugent.be>: > On 2018-06-07 13:24, Timo Kaufmann wrote: > >> I don't really agree but even if that was the case, the PARI stackwarn >> patch could have been handled through filtering within sage instead >> (which I proposed in that ticket). >> > > You proposed filtering *in the testsuite*. That comes back to my point > about fixing the testsuite: filtering in the testsuite only makes the tests > pass, but it doesn't really fix anything for end users. >
That was because in that case I didn't actually see the warning as an error / something to avoid. I simply introduced filtering in the testsuite to avoid having to add warnings to all the tests and making them even more brittle. If you disagree (which you apparently do) we could've instead added filtering directly to the sage<->pari interface. > The problem with your proposal is that in many cases, it is hard or > impossible to work around the bug. For example, I have no idea how to "work > around" build/pkgs/glpk/patches/error_recovery.patch > For what its worth, here is debians fix (self-labeled as "extra-hacky") for that issue: https://salsa.debian.org/science-team/sagemath/blob/master/debian/patches/dt-version-glpk-4.60-extra-hacky-fixes.patch Which kind of supports my points that (1) distributions will have to work around it anyways and (2) the solutions of the distributions are probably not as good as the solutions the sage community could come up with. In that specific case I opted to adopt the glpk patch for nixos because I don't really understand the debian fix (I barely understand the dails of the problem). So if you don't want to patch the upstream package, then the only remaining > option is making Sage worse (either by not implementing the functionality > which requires the patch, or by accepting that a bug cannot be fixed). > And I'm not saying there should be absolutely no patches, just that they should be the very last resort. So if working around the problem is really not possible and there exists no other solution it'll have to be a patch. Just make sure upstream is aware that sage and probably most distributions shipping sage will have to patch their sotware, maybe that will make them reconsider. In some cases where upstream has vanished and sage effectiely maintains the project through patches anyways, it may be a better idea to just fork the project. > I'm biased of course. >> > > We are all biased in our own ways... > > I should also add that my opinion is my opinion only. Other SageMath > developers may have different opinions. Of course. Unless somebody else chimes in to add a different opinion, I think its relatively safe to assume that the other devs think similarly. -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
