[Debian-science-sagemath] pari-sage or pari ?

[Ximin Luo]

jdemeyer at cage.ugent.be:
>> As a concrete example: you *do* have control over what code Sage accepts. So, as I suggested below, you can delay accepting certain patches into Sage, until upstream patches are applied - especially minor ones (3 lines) that have a major outside effect (~15 failed tests in Sage) - and encourage or require Sage contributors to first upstream their patches. Or, you write your code against the current bad upstream API, and add a TODO and a description of how to change it to use the good one, when your patch finally gets accepted.
> 
> That means releasing software with bugs for which there are known fixes, or with less features just because of upstream. Now *that* is not acceptabele fort me. So it's just a matter of priorities: my priority is making the best software.
> 

This is highly subjective, and this is the cost of interoperation.

We believe it's better to release software with minor bugs or less features, to make it easier to interoperate as a connected community of FOSS developers.

If it's a major bug, for sure we'll patch it. But many patches in Sage that I've seen, are not "major" or "urgent fixes", but minor things made just so Sage developers can use a slightly simpler API. This causes more pain for everyone else, even if it makes your lives slightly easier.

Because the point is subjective, let's not waste time discussing it further in a vague abstract way.

To make a more "objective" argument, I will have to go through `find build/pkgs/*/patches -type f | less` and discuss every single patch in turn, which I don't have the time for now. It's just a general background feeling I get from packaging Sage.

I acknowledge that I could be biased, because I only see the patches that break things for Debian. Possibly there are 10x more patches that you did more carefully, Sage is big after all.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git