kcrisman wrote: > > > On Nov 4, 2:22 pm, "ma...@mendelu.cz" <ma...@mendelu.cz> wrote: >>> We might also have an option for "fixed in our version", as many times >>> we will patch an spkg and simultaneously report it upstream. When we >>> eventually get the upstream fix in an update, we delete our patch. >> In other words, is this preferred way to fix broken Maxima commands? >> >> 1. Fix in maxima.spkg >> 2. Add test that the fixed spkg is used. >> >> I am asking because of work on >> trachttp://trac.sagemath.org/sage_trac/ticket/7325 >> (fixed in CVS Maxima few days ago). I fixed Maxima part in python code >> in the patch submitted to this trac, which seems to be not accepted. >> >> And what abouthttp://trac.sagemath.org/sage_trac/ticket/6479where I >> fixed maxima commands ic2 and bc2 directly in Python code (lines >> 322-328 and 341--346). Should this ticket been reopened and ic2, bc2 >> fixed as described above? > > It seems reasonable that one might be able fix or work around > something in Python/Sage but not have the time/expertise to do so in > the upstream package, so probably it would depend on the situation - > better to fix a bug than not to fix it because you're required to fix > it in the spkg. > > Upgrading spkgs all the time is also annoying, particularly since CVS > versions sometimes break other things. But if the bugfixer knew how > to fix it in a local skpg upgrade, presumably no one would be opposed > to that! > > - kcrisman
If one finds a workaround for a bug, IMHO one has a moral duty to let the upstream developer know of the bug. Tell them you have found a workaround, but it should still be reported upstream. So perhaps a * Workaround found; Bug reported upstream would be useful. Failing to fix something properly due to lack of time/expertise seems very reasonable. Not bothering to tell the upstream developers of a bug since you have worked around it, is not. So how about as a list: 1) N/A - Not an upstream bug 2) Not yet reported upstream; Will do shortly. 3) Reported upstream. 4) Fixed upstream 5) Workaround found; Bug reported upstream. 6) Completely fixed; Bug reported upstream There might be some argument for splitting number #3, depending on the state of what the upstream developers say. 1) N/A - Not an upstream bug 2) Not yet reported upstream; Will do shortly. 3) Reported upstream. Little or no feedback. 4) Reported upstream. Developers acknowledge bug. 5) Reported upstream. Developers deny it's a bug. 6) Fixed upstream. 7) Workaround found; Bug reported upstream. 8) Completely fixed; Bug reported upstream I think those 8 cover all I can think of, but there may be arguments for having more or less options. One might argue for splitting the "Fixed upstream" into two, depending whether it is in a stable release, or CVS. For example, I'm aware of an issue on ECL, which has been fixed in the upstream CVS, but has not to my knowledge been fixed in a stable release. In that case, there is some argument for not making a new .spkg, even if a fix exists. That would give up 9 options. I think there might always be something which does not fall into a nice category, so perhaps a 10th 'catch all' is needed too. 1) N/A - Not an upstream bug 2) Not yet reported upstream; Will do shortly. 3) Reported upstream. Little or no feedback. 4) Reported upstream. Developers acknowledge bug. 5) Reported upstream. Developers deny it's a bug. 6) Fixed upstream, in a later stable release. 7) Fixed upstream, but not in a stable release. 8) Workaround found; Bug reported upstream. 9) Completely fixed; Fix reported upstream 10) None of the above - read trac for reasoning. Dave --~--~---------~--~----~------------~-------~--~----~ To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
