On Apr 1, 2010, at 8:55 PM, Dr. David Kirkby wrote:
Robert Bradshaw wrote:
I believe this is very relevant to the discussion that's taking
place on sage-devel.
Thank you Robert. Forwarding that was very useful.
Begin forwarded message:
From: William Stein <wst...@gmail.com>
Date: March 21, 2010 11:09:31 AM PDT
To: sage-release <sage-rele...@googlegroups.com>
Subject: [sage-release] Sage releases
Reply-To: sage-rele...@googlegroups.com
Hi,
The last release (sage-4.3.4) illustrates that there are some
misunderstandings about when a release manager should actually
make an
official release.
The README.txt lists the following as the supported Sage platforms:
"PROCESSOR OPERATING SYSTEM
x86 32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
x86_64 64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
IA-64 Itanium 2 64-bit Linux -- Red Hat, SUSE
x86 Apple Mac OS X 10.5.x
PPC Apple Mac OS X 10.5.x"
To me, this means that we're claiming that each Sage release works
on
those platforms.
This suggests some ideas for how to do things better:
(1) We should change the above matrix to the following:
PROCESSOR OPERATING SYSTEM
x86 32-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
x86_64 64-bit Linux -- Debian, Ubuntu, CentOS (=Red Hat),
Fedora, openSUSE, Mandriva
IA-64 Itanium 2 64-bit Linux -- Red Hat, SUSE
x86 Apple Mac OS X 10.5, 10.6
PPC Apple Mac OS X 10.4, 10.5
SPARC Solaris 10
since OS X 10.6 support is very good now, and we decided a while ago
*not* to drop OS X 10.4, but to carefully officially support it.
Also, we better add Solaris 10 soon enough. There will also be
another line soon, I hope:
x86 Cygwin (Microsoft Windows)
(2) We should also specify that we only claim that Sage will build
with a generic install (+devel packages) of the latest officially
released version of one of the above OS's. We make no claims about
old or crufty OS versions.
IMHO, point 2 should be changed significantly.
It's not always possible for someone to install the latest release
of the operating system. People do not always have time. William
remarks he has installed Linux 1000 times and is fed up with it.
Florent Hivert remarks he tests Sage on openSUSE 11.1 and also said
he believes there is a release 11.1 virtual machine on boxen.
However, the latest official stable release of openSUSE is 11.2
which was released on November 12th, 2009.
We should not claim support on the latest stable release unless we
test on it.
If a newer release of some distribution is made, it would obviously
be useful to have that as a test platform, but until such time as
that is done, we should not claim to work on the latest stable
release. If at all possible, we should not break Sage so it fails to
work on older releases. If we have a 11.1 openSUSE virtual machine
now, then if a build farm is available, testing on 11.1 and the 11.2
should be possible if someone has the time to install an 11.2
virtual machine.
Linux has a poor record of backward compatibility (some
distributions are worst than others), so it's always possible a new
release of some distribution will be made which can not build Sage.
IMHO, there is no need to remove that distribution from the support
Matrix. It is better to just list the version we know works, and
hopefully try to sort things out so Sage builds on the latest version.
Likewise, t2.math is not running the latest release of Solaris 10,
but Solaris 10 update 7 (05/09). I usually test Sage on Solaris 10
(03/05 - the first release). If it builds on that, you can be
99.999% sure it will build on the latest release of Solaris, as
Solaris has an excellent record of backwards compatibility. But we
can't claim it works on the first release of Solaris 10 unless we
test every release on it, which is not practical given there is no
machine running the first release generally available, and
furthermore, 't2' would not support the first release of Solaris 10.
Also, at least in the case of Solaris 10, there are no suitable
development packages officially available. Installing a developer
release of Solaris 10, you get gcc 3.4.3, which is too old to build
Sage. It is better to say gcc 4.4.1 configured to use the Sun linker
and assembler, which is what is used on 't2' now, though we would
expect any gcc >= 4.0.1 to work.
(3) We should never, never, ever release another version of Sage,
unless it actually builds and passes its test suite on all of the
above.
I'm glad William has come around to my way of thinking on this -
i.e. we need to test on all the supported platforms before any
release is made. I think Minh's matrix he made we be a good starting
point for this.
(4) However, sometimes a pseudo-release that doesn't pass (3) is
very
useful, e.g., before Sage Days (like right now), and targeted for
experts. In such cases, we could do a "beta" release, e.g., 4.3.4
could have been:
sage-4.3.4.beta.tar
and there could never be a 4.3.4 that isn't beta. In case of a
beta,
this would mean that:
(a) we continue to host everything related to 4.3.3 on the main
website.
(b) we make the beta source and binaries available.
I don't think the point that there should never be a 4.3.4 that is
not beta necessary. It is quite common (usual method) to make a beta
release available, then make a non-beta (i.e. fully tested) version
available with the same version number.
(I don't see any harm in making all the alphas available on the web
site either, as long as it is clear that these are alpha releases.)
+1 to all of the above. And Kudos top those who actually put in the
insane amount of work required to do release management (as opposed
to those who just sit around and talk about it).
Robert, before saying +1 to all the above, you should ask yourself
if all of the above is practical. IMHO, it is not.
I think this is the main point of disagreement, IMHO it is practical
and worthwhile (though a lot of work, and we may have to temporarily
thin the list). I agree with you that "latest official release" should
be taken a bit loosely--it may take some time to upgrade our build
farms and if there are issues to sort them out. I think the main point
was that we're not making promises if the OS is not reasonably up to
date (though technically there's no reason it shouldn't still work,
and we make all past releases available as well).
(5) Regarding the technical issues with testing the above, it's of
course possible using a build farm. However, maintaining such a
thing
takes a lot of effort, and so far I have had to do it all myself on
boxen, and I simply don't have the time (or inclination). We
might
have to *temporarily* shrink our list of supported platforms until
either I can hire somebody, I get more time, or somebody steps up
and
volunteers to manage a virtual build farm. I've probably
installed
Linux more than 1000 times in my life, and I'm tired of installing,
upgrading, etc. Linux. I used to love it. Thus I'm sure somebody
out
there loves to. Anybody in Seattle?
I'm also glad William agrees the list of supported platforms should
be reduced until such time as we can test on them. Previously he
stated he definitely did not agree with me.
http://groups.google.com/group/sage-devel/msg/47ca574f0348fb8b
Since there is agreement to build on test on each supported
platform, Peter Jeremy's point that "supported" should mean binaries
are available is at least worth considering. If the testing is done
on the *.math.washington.edu network, then making a binary should be
reasonably possible, as it only needs 'sage -bdist' to be run to
create the binary.
However, if verification of a successful build comes from someone
using a system that is not on the *.math.washington.edu network, it
may be impractical for them to make the binary available, due to the
bandwidth needed to upload it.
Their reports should still be useful. (Ideally there should be an
option when running tests (building?) that would automatically report
back with the results and system specs.) I don't think having the
bandwidth to upload half a gigabyte is that rare--especially from
other universities around the world.
- Robert
--
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, reply using "remove me" as the subject.
