I think that your post is focusing too much on tests, as if the only
purpose of Sage is to pass its testsuite. It's actually the other way
around: the purpose of the testsuite is to ensure that Sage functions
correctly. By patching the testsuite to accept buggy output anyway,
you're not really fixing anything, just hiding the problem.
By the way, the difference that you make between category 2 and 3 of
patches is not so relevant: I would argue that the PARI stackwarn.patch
is more essential (as in: more likely to affect users) than the
re_match_index-issue_27177.patch Python patch.
I would propose to make it a policy to only include sage patches when
*absolutely necessary*. If ugly workarounds or even monkey-patching is
necessary
for that, that sucks. But distributions will usually come up with even
uglier
workarounds (since they don't know the code) anyways, just resulting in
duplication of effort.
There is a constant ongoing tension between downstream (Sage), upstream
(PARI, Python, ...) and distributions (Debian, NixOS, ...). Nobody wants
to be the one needing to fix the problem. So upstream tries to convince
downstream that the problem is on their side, downstream tries to push
the problem to distributions and distributions probably bother both
upstream and downstream.
You seem to be blaming Sage for patching its dependencies, but in many
cases it would be even more valid to blame upstream for not accepting
those patches (or for not making a new release containing those
patches). That way, the problem is really fixed for everybody: not just
Sage but all users of a package. Or you could blame your distro for not
applying that patch too.
Of all Sage developers, I could very well be the one adding most patches
to its packages. Whenever I feel the need for patching a package, I ask
myself what the best solution to the problem is: it could be an upstream
patch or it could be a change in Sage. When it's an upstream patch, I
make sure that it fixes a genuine upstream bug and I submit the patch.
In most cases, the patch is then accepted upstream. However, when it's
not accepted (for whatever reason), I don't want to do the effort of
figuring out a solution without patching the package. I feel like that
is just a waste of time since I already have a working solution for the
problem (patching the package) and working around a problem is often
harder than fixing it.
What I'm trying to say is that patching a package in Sage is always a
very deliberate conscious choice and not just "whatever, let's patch
this package". So while I certainly understand the concerns of the
distributions, I'm personally not really willing to change anything.
Jeroen.
--
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.
