If 4.3 plus one single patch would do it, I think it's completely worth while. If you know what that patch should be, make a ticket and post it. Having a version that works on Solaris out of the box is worth having an out of sequence release. Then we just need a source tarball at minimum, right? Are there sufficiently few architectures that making binaries is reasonable? If it's just source, then I'm sure we can give you a sequence of mercurial commands to build the appropriate tarball from one patch.
However, I agree with Robert that requiring patch authors to test their changes on every system Sage supports is unreasonable. That should be part of the release manager's job (though maybe we need better build farms and scripts to facilitate this). David On Thu, Jan 28, 2010 at 6:48 AM, Dr. David Kirkby <david.kir...@onetel.net>wrote: > Robert Bradshaw wrote: > >> On Jan 27, 2010, at 11:24 AM, Dr. David Kirkby wrote: >> > > It does not seem unreasonable to check ones patches on Solaris, OS X and >>> one linux distro. >>> >> >> I would say that this is unreasonable. Especially for casual or first-time >> contributors. But we've had this discussion before. Long term, the solution >> is to automate; there was some talk about and even some works towards this >> at the last Sage days. >> > > I can see the point for someone contributing their first few contributions. > But personally I don't think it is unreasonable that people are aware Sage > is a multi-platform and that things need to work on all Supported platforms. > > I've not seen any comments from William here about the policy with respect > to Solaris. > > I agree a build farm is the best solution. I was a member of the wireshark > developer group at one time, as I was expecting to need to devlop that for > some commerical contract, which never came off. But I was *very* impressed > with how their build farm worked. > > Basically CVS or similar was used, so developers would upload changes to a > central server. The build farm would build the software on multiple > platforms, and send an email of any breakages to developers. The email also > listed those who had made commits since the last successful build. VERY > impressive. > > Unfortunately, 't2' would be a bottleneck on any such process due to it's > dismal performance. > > > Solaris 10 on x86 could be installed in Virtualbox, but I don't know how >>> well Sage would work on that. My guess is there would be some issues which >>> would need resolving. >>> >> >> I'm sure that having any Solaris, even a virtualized x86 one, as part of >> the existing build farm setup would be a step forward. You're probably right >> about there being outstanding issues. >> > > Yes. Solaris 10 on x86 would probably be the best. Open Solaris is quite > different. However, I suspect there are lots of bits of code in Sage that > assume Solaris=SPARC. > > Better still would be a fast SPARC, like an M3000. It looks like the buyout > of Sun by Oracle has taken place finally, as the URL to that machine is no > longer on www.sun.com. > > > http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/031588.htm > > That's probably around $20,000 for a quad core 2.75 GHz. > > > > The biggest problem seems to be to the Sage library. That's mainly where >>> there needs to be more testing on Solaris. The individual .spkg files seem >>> to present less problem. >>> >> >> I find this surprising--most of the Sage library is pure Python (which >> should be platform independent, and most of the dependance is in stuff like >> / vs \ for paths which is only an issue for Windows porting), or Cython >> (which again should be platform independent for most of the code (please >> file bugs if its not), and over half of the modules don't link against >> anything but math and gmp). Of course, there are probably some nasty >> surprises in there as well (libsingular always seems a bear to port...) >> > > Maybe I jumped the gun a bit there. The long-standing issue was with the > library, but in the use of SCons for building. That used to pick the GNU C > compiler 'gcc' to build C files, then switch to the Sun C++ compiler 'CC' to > build C++ files. > > The recent issue with the gcc compiler bug was seen in the library. > > This issue is only with the library. > > But I guess three things are not a huge number, considering the other > issues we have had. So I retract that statement! It probably seems that way > to me, all the issues since 4.2 have been in some way related to the library > - everything else works. > > > Fair enough. I'll write something on that. But it would be good if I had a >>> release that I can tell people to build - currently there is no way to get a >>> successful build on t2 unless I disable the Sun compilers. But the fix for >>> that is in trac >>> >> >> Of course it's a chicken and egg problem--until one can just unpack the >> sources and type make fewer people will bother to test on that platform. >> > > Yes, which is why I think a 4.3.0.1 release is desirable. > > > There are several reasons I feel a 4.3.0.1 would be desirable. >>> >> >> Or would that be 4.3.1.1? >> > > No, since it would have to be based on the 4.3 sources, not the 4.3.1 > sources. > > 4.3 plus one single patch would do it. > > 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<sage-devel%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- 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
