Re: [sage-devel] A suggestion for make
On 2015-05-24 20:41, john_perry_usm wrote: Does it seem reasonable to add a prompt at the beginning of the Makefile that points this out, suggests './sage -b' if they just want to fix some changes I am very much against this. The normal way to rebuild is to use make, while ./sage -b should only be used if you know what you're doing. I have seen several bug reports which were just people forgetting to run make. So my impression is that we need to advertise ./sage -b less, not more. I agree with Simon that the docs are annoying. However, I usually run make in a different shell window. I can already run and test Sage while the documentation is still building. Jeroen. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] A suggestion for make
I once knew that sage -b is the proper way to rebuild after a small change to Sage, but I've been working with other software since then. On most software, make is the ordinary way to go, so it tripped lightly off my fingers. Thereby I discovered that typing make rebuilds an awful lot of sage, including files otherwise undefiled by my hands (so to speak), and not dependent on my change. Maybe it rebuilds the whole deal? This can be an easy mistake to make, though I reckon I'm the only one dumb enough to do it twice in five minutes in two separate installations. Does it seem reasonable to add a prompt at the beginning of the Makefile that points this out, suggests './sage -b' if they just want to fix some changes, and asks the user if s/he really wants to rebuild all of Sage? Or am I completely wrong about what is going on? john perry -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[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
[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
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
