2018-06-07 11:12 GMT+02:00 Jeroen Demeyer <j.deme...@ugent.be>: > 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.
Of course. But the testsuite should always pass as long as sage is "working". Its the best proxy available. Sometimes the test suite is a bit too brittle. By patching the testsuite to accept buggy output anyway, you're not really > fixing anything, just hiding the problem. > If its a functional bug (`2 + 2 = 5`) I agree. But if its just a formatting bug, that should not fail the test suite in my opinion. 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 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). Thats really my main point: use other solutions if possible. > 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. > I'd argue distributions is the worst place to fix problems because that results in duplication of work and the people fixing the issues might not know what they're doing. > 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. > I really don't want to blame anyone (especially not you, I'm grateful that you already reviewed many of my patches). Sorry if it sounds that way. I'm just proposing to choose the most pragmatic solution. Its always best to fix the problem as far upstream as possible: Of course it would be ideal if the upstream packages would accept those patches. But if that is not the case for various reasons, I'm arguing that working around it in sage is the next best place. > 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. I very much agree with that process. As you said, fixing problems upstream fixes them for everybody. > 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. > I'm arguing that (if distributions are considered first class citizens) it is very much not a waste of time. I think the ticket should be blocked until upstream has accepted the patch or it is clear they won't. If the ticket author doesn't work around the problem in the second case, distributions will have to. So the time is spent either way. Even if distributions just adopt the patch to the upstream package, figuring out which patch is needed, adopting it, testing it etc. takes significant time. I understand that your time is very valuable and you can do with it whatever you want and I'm not saying you should solve all the problems. I'm just saying we should adopt a policy and adhere to it as a community. 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. > I'm sad to hear that. I think it would be best for sage and gain it a lot of users and potential contributors if the community would invest some effort into being less difficult to package. I'm biased of course. -- 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.
