Hi folks,

On Sun, Mar 21, 2010 at 9:10 PM, Florent Hivert
<[email protected]> wrote:

<SNIP>

> I don't know what to do and I've no more time to investigate (I already spend
> half of my week-end on it together with the rebase of sage-combinat
> queue). Also I must confess I'm far from being an expert on those issues. So
> maybe, if there is one in the sage project, it's a good time to step up and
> fix this quickly.
>
> If this doesn't happen, here is my feeling:
> <disclaimer>
> This is by no means an attack against the release managers. Many thanks to
> them for there hard work, but shit happens. And we have to find ways to 
> prevent
> them and to solve them quickly.
> </disclaimer>
>
> I think that we can't seriously make a release which is broken on half the
> distros. Shouldn't we revert R from it's previous version, remove gd and make
> as soon as possible a fix release until this is sorted out ?

I think I owe everyone an explanation why the Sage 4.3.4 release is
broken for Fedora and openSUSE. Before I announce a release, whether
it be an alpha release or an rc, I would build and long doctest it on
the following machines:

* sage.math: Ubuntu 8.04.4 LTS, 24 cores, Intel(R) Xeon(R) CPU X7460 @
2.66GHz, 132 GB RAM, GCC 4.2.4

* bsd.math: Mac OS X 10.6.2, 4 cores, Intel Xeon @ 2.66 GHz, 8 GB RAM, GCC 4.2.1

* winxp1 (Cygwin virtual machine on boxen.math): CYGWIN_NT-5.1, 1
core, Intel(R) Xeon(R) CPU X7460 @ 2.66GHz, 2 GB RAM, GCC 4.3.4

* t2.math: Sun T5240 CoolThreads server, 16 cores, 1167 MHz T2+
Coolthreads CPU, 32 GB RAM, Solaris 10 update 6, GCC 4.4.1

* rosemary.math: Red Hat Enterprise Linux Server 5.4, 24 cores,
Intel(R) Xeon(R) CPU X7460 @ 2.66GHz, 130 GB RAM, GCC 4.1.2

I don't build on my own machine because my MacBook is rather limited
in its hardware. That machine has a Core 2 Duo CPU with 1 GB RAM, dual
booting Mac OS X 10.4.11 and Ubuntu 9.10 desktop edition. My normal
work flow is to boot the Ubuntu partition and work from there. If I
build and run all doctests with the "-long" option, it would consume a
lot of system resources, heat up the machine, and adversely affect the
responsiveness of the XFCE desktop environment. It is Autumn over here
in Australia. During humid days, the machine could be very
unresponsive due to being over heated. That rules out the option of
building and doctesting during the day.

I also have the option of building and doctesting overnight. However,
my monthly Internet quota is rather limited. To constantly test on my
machine, I would need to download various source tarball versions as
well as performing upgrades with the Sage option "-upgrade". That
would significantly eat into my download quota, which once exceeded
would mean that my download and upload rates would crawl at
approximately 7 KB/s.

Now comes the option of building and doctesting on machines at my
institution. I regret to say that I no longer have access to any of
them. I have graduated so I no longer have access to the computer in
my former office. A good thing about that machine is that, from there
I could ssh to a server that runs openSUSE. I'm no longer working at
that institution, so less machines to play with.

There is also the option to build and doctest on the build farm
consisting of Linux virtual machines on boxen.math. William constantly
does this after a source tarball is released, so I have tried as much
as possible not to step on his toes by building and doctesting on the
build farm of Linux virtual machines.

Now comes the machines within the Skynet network of computers. I have
the option to build and doctest on most machines on that network. The
only machines Sage won't build are likely to be those running x86 or
SPARC Solaris. From my experience with machines on Skynet, building
and doctesting Sage on some of the Linux machines could actually crash
the machine. Most times for me, such a crash would result in bringing
a machine down, or even bringing down the primary network node that is
the gateway to the other machines on the network. When the primary
node is down no-one can login to Skynet. The implication is
significant. Not only does it affect Sage, but also developers of
upstream projects. Some developers of projects that Sage depends on,
e.g. FLINT and ATLAS to name two, use Skynet to develop and test code.
To crash a Skynet network node would be an act of impoliteness to Sage
developers who has access to Skynet, and also to other users of that
network. For these reasons, I have tried to steer clear of compiling
and doctesting Sage on Skynet.

-- 
Regards
Minh Van Nguyen

-- 
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to 
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

To unsubscribe from this group, send email to 
sage-devel+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Reply via email to