Hi folks, On Tue, Oct 27, 2009 at 5:22 AM, William Stein <wst...@gmail.com> wrote: > > Hi, > > I wonder why everybody (*) making suggestions has never put together a > single Sage release themselves, yet everybody who has done significant > work putting together Sage releases, organizing the web page, mirror > binaries, etc., has completely refrained from making any suggestions?
I have two excuses. Lame excuse: I was busy preparing a draft of my Honours thesis. Good excuse: I wanted to spend some time gathering my thoughts on the issue of maintaining a conservative series of releases. Here are my thoughts. Let's imagine for the sake of discussion that we have two separate releases. On the one hand, there is a conservative double point release series like Sage 4.2.x which only have bug fixes and also bug fixes that have been back ported from major releases. Such bug fixes include fixing bugs in the Sage standard library, bug fixes in the Sage standard documentation, updating standard packages but not upgrading spkg's to upstream releases, etc. On the other hand, we have a major single dot release like Sage 4.x which includes new features in addition to bug fixes that have been back ported to the Sage 4.2.x series. Furthermore, both the double dot point and major releases are released more or less roughly at the same time. For something close to what I'm talking about, refer to the current situation with Python in which there is a maintenance release for Python 2.6.x, and at the same time there is a major release (i.e. Python 3.x) that includes new features and backward incompatible changes. Now let's explore ramifications regarding human resources of having two separate branches: a conservative branch, and a major branch. One of the first questions that come to my mind is: Are there human resources around to maintain two separate branches? And if so, how can such resources be divided between the above two branches? Who are willing to step up to the task of doing a maintenance release for the Sage 4.2.x series? In order to understand the latter question, assume for the sake of discussion that new features, backward incompatible changes, bug fixes and other wild/crazy stuffs can go into the major release. Do we need at least two release managers: one for the conservative release, and one for the major release? On the issue of release management, see the release management wiki page [1] for an incomplete list of tasks involved in managing a release. Other questions include: Who are available/willing to fix bugs in a conservative release? Who are available/willing to back-port bug fixes from a major release? Who are available/willing to test and review bug fixes for a conservative release as well as for a major release? What can we do to empower users to explore a bug, narrow down its cause(s), fix the bug, and produce a patch? I don't claim to have answers to any of the above questions. Now let's explore the issue of infrastructure. We require a farm consisting of different systems for testing and building Sage. This is already in place in the form of the dozen Linux virtual machines hosted on boxen.math, machines on the Sage network and SkyNet, and any machines that people can get their hands on. From download statistics, Windows users account for the majority of users of Sage. Of the people who are using Sage under Windows XP, under Windows Vista, or Windows 7, how many of them are willing to help with developing Sage under Windows? This can range from using Sage under Windows to testing Sage and even producing patches. Similar questions can be raised for Mac OS X. From my experience, people who use Sage under OS X have been actively contributing to the OS X port of Sage. It is reported, and I know from personal experience, that Sage 4.1.2 compiles and work OK on Intel Mac OS X 10.4.11. People who use Sage on a Mac have been reported to do so under Mac OS X 10.4.x, 10.5.x and 10.6.x in addition to different CPU architectures (Intel, PowerPC, G4, G5). As for Linux, there are reports that people have used or tried to compile Sage under Arch Linux, Gentoo, SUSE 10.x, RHEL 5.3, and Slackware. There might be other exotic Linux distributions that I have missed. Does the Sage development infrastructure contain all such machines listed above? Contrast the above to the actual state of the Sage infrastructure. The Linux virtual machines on boxen.math at their current state consist of the following Linux distributions in both 32- and 64-bit versions: CentOS 5.3, Debian 5.0, Fedora 11, Mandriva 2009.1, openSUSE 11.1, and Ubuntu 9.04. The machine bsd.math is a MacIntel running OS X 10.6.1. The machine t2.math is a SPARC machine running Solaris 10. I've heard that disk.math runs x86 OpenSolaris 10. The SkyNet cluster consists of the following machines on which Sage is known to compile and run OK: * cicero: x86 Fedora 9 * eno: x86_64 Fedora 9 * lena: x86_64 RHEL Server 5.3 * menas: x86_64 openSUSE 11.1 There are also two IA64 machines on SkyNet, one running openSUSE and the other running RHEL. SkyNet also has a number of Solaris machines. At the moment, Sage is known to fail to compile on either of the Itanium machines as well as on the Solaris machines (I might be wrong here). William Stein also has access to the latest version of Red Hat, namely the machine rosemary.math, which runs x86_64 RHEL Server 5.4. For release management, it's a good idea for a release manager to have access to machines that make up the Sage development infrastructure. In addition to that, a release manager also needs to have access to Windows machines (XP, Vista, Win7) together with Cygwin and/or the latest version of MSVC. This might or might not be necessary, depending on your point of view. However, since the Cygwin port is nearly complete (minus some failures), one also needs to test a release of Sage on Cygwin. As for MSVC, I'm not optimistic about anyone having access to the latest version of that expensive development environment. There have also been discussions about porting Sage to AIX and HP-UX. But how many people in the Sage community have access to either of those platforms? David Kirkby has access to an AIX machine and he has tested some patches/packages on it. I recently sent a request to OpenAIX for a free account on an AIX machine, but have so far received no reply. David Kirkby said that the person in charge of OpenAIX is on vacation. Notwithstanding issues of human resources and development infrastructure, how are we going to sort out the issue of mirroring out two separate releases at the same time? Say that we have two versions: a conservative version with only bug fixes, and a major version with new features and backward incompatibilities. Furthermore, both are released at the same time. Are we going to mirror out both releases? If so, what changes need to be made to web sites, and web sites of mirrors around the world, so that people won't be confused about information presented on web sites? For a whole year during 2008 or so, Harald Schilly was the only person who maintained the Sage web site. Python has two different releases: a bug fixes release for 2.6.x, and a new features release in the form of 3.x. Can we mimic how the Python web masters structure their web sites, in particular the download page [2] and the documentation page [3]? If people want to upgrade, they have the choice of upgrading to the bug fixes only release, or upgrade to the major release. At the moment, I understand that any of these two tasks can be accomplished in two ways. Download the relevant source or binary tarballs by going to the relevant download pages; or do an upgrade with "./sage -upgrade". However, note that the current behaviour of "./sage -upgrade" is to download updates from a mirror. How can mirrors and/or the upgrade script be restructured in such a way so that if you want to upgrade from Sage 4.2 to 4.2.1 you don't end up with 4.3? At the moment, this is not an issue because only one repository is mirrored out. If we are to maintain a conservative release in addition to a major release, I think it would require maintaining two separate repositories that need to be somehow kept separate on each mirror, including on the master server. By now, I guess you are tired of me rambling on about human resources this and development infrastructure that. And you ask yourself, "Is this guy going to do anything about maintaining a conservative release? Or is he just making a lot of hot air?" So to put my money (err... my free-time-away-from-work) where my mouth is, I propose to take the Sage 4.2 release and maintain a bug fixes only Sage 4.2.x series. I want to experiment with maintaining the Sage 4.2.x series for at most six months and would step up to be a release manager for that bug fixes only series. After six months, I would drop maintenance of that series and would take on the major release current at that time and continue on maintaining a bug fixes only series of that major release. My aim is to cater to people who don't want to upgrade to major changes/features and the latest and greatest, but are happy to upgrade to bug fixes only releases. While doing a maintenance release of Sage 4.2, people should use for development whatever alpha or rc versions of Sage that Mike Hansen releases. Sage is a volunteer project whose success is due to its user base, the untiring commitment of its growing development community, as well as the countless hours of volunteer time its community has devoted to it. I consider it a privilege to volunteer my time to be release manager of the Sage 4.2.x bug fixes series. Any serious objections why I shouldn't maintain the Sage 4.2.x series for at most six months? [1] http://wiki.sagemath.org/release [2] http://www.python.org/download/ [3] http://www.python.org/doc/ -- Regards Minh Van Nguyen --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
