I believe this is very relevant to the discussion that's taking place
on sage-devel.
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.
(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.
(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.
+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).
(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'll try my hand at doing something this summer. Ideally this will be
a pull system, so anyone can easily donate cycles to make sure Sage
keeps working on his or her platform of choice.
- 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.
