Jason Grout wrote: > Dr. David Kirkby wrote: >> 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. >> > > > Often, both 4 and 8 are true. Being fixed (including workarounds) in > Sage temporarily is orthogonal to the bug reported upstream.
True, 4 and 8 can both be true, but are often not true. This is the problems with the whole trac system. Often things should be in more than one category. I used to put a lot in 'Solaris' but now realise that they are probably issues on any non-linux platform, so have put them in 'porting'. Then they are really build issues, so perhaps they should go there. I must admit, I'm often at a loss at exactly what category to use. > If 8 or 9 is the case, then usually we would just close the trac ticket > as fixed. What do you think about that? > > Jason I do agree the trac would be closed in case 8 or 9. But a workaround is often not a completely satisfactory solution. For example, a bug in ATLAS means it dumped core during a tuning process on Solaris systems with the sun4v architecture. A workaround was implemented on Solaris, which returned a reasonable value for a tuning parameter, rather than optimising it. That was closed. http://trac.sagemath.org/sage_trac/ticket/6276 Really that should have been a case 8, as the underlying problem was not solved. Later I thought about this, and realised that the workaround was applied on any Solaris system, when the bug had only been seen on sun4v systems, so I restricted it to sun4v machines only http://trac.sagemath.org/sage_trac/ticket/6558 Again, that is not a complete fix, as the workaround means there is a performance degradation on sun4v machines. So despite the fact this bug has been closed twice with workarounds, the underlying problem is not fully solved. Perhaps searching for bugs were workarounds have been found would be useful from time to time. BTW, this ATLAS bug has come back to haunt me yet again! I'm in the process of building Sage 4.2 on an old SPARC system running the first release of Solaris 10. Then it will work on any Solaris 10 system. However, since the machine I'm building on is sun4u, not sun4v, the fix will not be applied and it might still crash on sun4v systems. So workarounds are not in my mind complete solutions. 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 -~----------~----~----~----~------~----~------~--~---
