Minh Nguyen wrote:
Hi folks,
On Sun, Mar 21, 2010 at 9:10 PM, Florent Hivert
<florent.hiv...@univ-rouen.fr> 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
I think the strategy for making releases is wrong. At the moment, it basically
works like this.
* A release candidate is created, time is given for people to shout if it does
not work. If there are no reports of failures, or the reports are missed, so the
release goes ahead. Often the time to shout is < 1 week.
A better solution would be:
1) Make the final release candidate.
2) Don't make the release until there is confirmation of a successful build, and
all doctests passing on all supported platforms.
Perhaps have a wiki page, with spaces for each successful build. When, and only
when, that shows a successful build+doctests pass on every supported platform,
is the release made.
If you ever watch F1 racing, you will know that at pitstops a flags is held in
front of the F1 car until the flagman (for what of a better expression) gets
confirmation that the tyres are changed and/or the car is refueled. Only then is
the driver able to drive away. F1 teams do *not* use a method where the driver
waits 20 seconds, then goes unless he gets a message that there is a problem -
it would be dangerous.
It seems we have a fundamentally flawed strategy in place.
I'm a bit busy now, but the simplest solution might be to put near the top of
the iconv package
if [ "x$UNAME" != xSunOS ] && [ "x$UNAME" != xCYGWIN ] then ;
exit 0
fi
This avoids iconv being built on anything except Solaris or Cygwin which are two
platforms it is needed on. But there may be others, such as some of the cut-down
linux versions may not have iconv, or not a sufficiently powerful one to build R.
I don't have time to do that until around 2100 GMT today. (9 hours from now).
It would be worth checking if there are any updates available to 'gd' as the
failure of 'gd' to honor one of its own flags (something like
--with-iconv-path=') must I believe be a bug in gd.
If someone does not beat me to it, I'll get an untested hack out today by around
2100 GMT.
Had R been tested on Solaris, before someone updated the package, and ignored
the warnings issued by the configure script, none of this mess would have happened.
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
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.
