It seems best to just file a trac ticket - I'm not sure what the downside is to that. Perhaps we could make a new "milestone" for such issues, since they don't quite fit in "feature" or "wishlist". But I think it would be confusing to do something apart from trac.
-M. Hampton On Jul 21, 11:20 am, "Dr. David Kirkby" <david.kir...@onetel.net> wrote: > William Stein wrote: > > On Tue, Jul 21, 2009 at 9:51 AM, Dr. David > > Kirkby<david.kir...@onetel.net> wrote: > >> Sometimes when I create a patch, or look at work of others, I see > >> potential issues that might come back to haunt us at a later date. For > >> example. > > >> 1) Whilst updating a polybori patch, I noticed something done some time > >> back, that I think might have an impact on Solaris. I don't have the > >> time to check it fully. It would only happen if Sage is built in debug > >> mode. It's hardly a critical issue, but I think it worth noting. > > >> 2) I'm applying a patch to pari, which involves commenting out a couple > >> of lines of code that cause hassle on Solaris when building the > >> 'modified sage library code'. > > >> The patch was suggested by William, it does work, but I think it is fair > >> to say neither of us have really investigated the effect this might > >> have. To do so would be huge amount of work, and probably result in the > >> conclusion it can't hurt. > > > I can't remember now exactly what I did, but I think that it was *not* > > ever my intention that this actually get into Sage. It was just meant > > to be a quick hack to get passed that point and finish building Sage. > > One should figure out a correct fix by consulting with the pari > > developers who are very very responsive. > > The problem is, it is not the pari distribution that shows this problem. > Pari compiles without any problems. > > The problem is in the 'modified sage library code', which includes this > header file, causes the problem on Solaris. > > Realistically, it would be better if whoever wrote that library code > discussed it with the pari developers, as they know why they included > the file. > > Ignoring that specific issue, what is your thoughts in general about > having some sort of trac ticket or other place where people list > potential problems for the future? With the best will in the world, if a > new issue of Sage was never released without some issues remaining, the > rate of progress would drop to a crawl. > > >> 3) I was going to apply a patch to singular, which is a bit of a hack. > >> It will work and will never cause any problems, but it is far from > >> clean. A better solution would be to resolve the underlying problems, > >> which are probably an autoconf bug or a bug in the singular build > >> system. Someone else is looking into that one, but the fix is not going > >> to be immediate. > > >> 4) An atlas patch will have a (I believe small) impact on Solaris sun4v > >> systems, and if Sun can sort out the library, will no longer be needed. > > >> It seems to me there should be a central location where people can add > >> to a list of potential problems that might just come back to bit us in > >> the future. > > >> Perhaps one trac ticket 'Potential issues in X' and another 'Potential > >> issues in Y' where anyone adds any potential issues they see, which > >> might be a problem in package X or Y at some later date, but which are > >> of low priority, or unlikely to occur. > > >> Dave --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
