On 06/24/10 04:20 PM, Volker Braun wrote:
Probably makes sense for bugs that produce obviously wrong results,
but what about bugs in the makesystem / autotools abuse / enabling of
shared libraries?
I don't fully understand you here.
Sometimes it is difficult to really get to the bottom of a problem, but that is
no reason it should not be reported upstream.
I think the contact should be made with the developers of the code that presents
the problem.
If they make use of broken version of autoconf or automake, then they should at
least be aware the code they are distributing is broken.
If it is proved to be a compiler bug, it should be reported to the gcc list.
1) Sometimes you only have time for a quick build fix where doing
things right might require a major effort.
Unfortunately that is far too common in Sage (see my post about the gcc_fake and
numpy. Someone's quck fix is someone elses big problem - especially when they
don't even document their quick fix)
I think there needs to be a separation between:
1) Letting the upstream developers know there is a problem.
2) Providing the upstream developers with a fully professional patch, tested on
a wide range of platforms.
I was only suggesting that (1) is mandatory. (2) would be nice of course, but
that may often not be practical.
My feeling is that if you find a problem in code, fix it (however good/bad you
do it), then the *problem* should be reported upstream. Until such time as the
problem has been reported, a positive review should not be given.
If everyone did that, a lot more problems would be reported upstream I feel.
2) Testing, say, new autotools through a Sage release is a great way
to ensure that it builds on all platforms.
I don't really see how that is related to my post.
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
