[sage-devel] Re: Suggestion to make reporting bugs upstream MANDATORY for Positive review.
On 6/24/10 5:54 AM, Dr. David Kirkby wrote: Here's a suggestion, which I think could be useful. If a reviewer sees that a bug on trac is an upstream bug, that they are required to see evidence that this has been reported upstream before the fix gets a positive review. Hence AUTHOR MUST state he has reported the bug upstream, and if so how. Sometimes that will be an email, but the ticket needs to say who it was emailed to and what date. Better still, if its a bug like in ATLAS, Python etc, where there is an online database, post a link to that. REVIEWER MUST NOT GIVE POSITIVE REVIEW unless he/she is satisfied a bug has reported upstream when appropriate. This will have several advantages in the long run. 1) Everyone (not just Sage developers) will benefit if a bug gets fixed upstream. 2) If the upstream developers say it is not a bug, then we should investigate in Sage whether or not there was perhaps a mistake in the bug fix. 3) When new releases of the upstream packages are made, they should have less bugs that Sage needs to work around. 4) If it becomes clear that we don't know who to report the bug to, that would need fixing in SPKG.txt Obviously many bugs in Sage have nothing to do with upstream packages, in which case this would not apply. But where the bug is clearly an upstream one, IMHO we make reporting it upstream a necessary condition before a positive review can be given. Does anyone have any comments? This seems reasonable to me. Thanks, Jason -- 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
Re: [sage-devel] Re: Suggestion to make reporting bugs upstream MANDATORY for Positive review.
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
[sage-devel] Re: Suggestion to make reporting bugs upstream MANDATORY for Positive review.
Probably makes sense for bugs that produce obviously wrong results, but what about bugs in the makesystem / autotools abuse / enabling of shared libraries? 1) Sometimes you only have time for a quick build fix where doing things right might require a major effort. 2) Testing, say, new autotools through a Sage release is a great way to ensure that it builds on all platforms. -- 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