I'd like to add as a goal that Sage 4.0 works with versions of its
dependencies available from the relevant upstreams.
For context, I would very much like to be able to package Sage 4.0 for
Debian once it comes out, since I find the current state of having Sage
3.0.5 from last July to be somewhat embarrassing. However, updating Sage
in Debian is really difficult because most Sage releases use a version of
at least one of its dependencies that could not reasonably be packaged for
use both in Sage and outside of Sage. This has been a problem both for my
efforts and for the people working on making Sage available in Fedora.
I like that Sage has a development model where fixing a bug in Sage
resulting from a dependency does not require waiting for an upstream
release, since this helps keep progress moving quickly. However, I would
find it incredibly helpful if every 3 or 6 months Sage did a release that
worked with upstream releases of its dependencies. Those releases would
then be packaged by distributions. This model is very similar to how a
lot of projects do unstable development for N months before doing a stable
release that can be shipped by distributions. It seems to me that major
releases like Sage 4.0 would be good candidates for these.
I want to be really clear that I'm not asking that Sage change its rapid
development model of aggressively fixing bugs in its dependencies. I'm
only requesting that Sage occasionally do a release that works with
dependencies that are available from the relevant upstream developers.
What do people think about this proposal?
There are basically two pieces of work that would be involved in making
Sage 4.0 use only upstream versions of dependencies.
The first is upgrading CVS/SVN versions of dependencies to actual
releases. I notice the Sage currently has an SVN version of jqueryui, an
SVN version of matplotlib, and an SVN version of ghmm (to be fair, ghmm
hasn't released is ages, so I don't blame Sage for that one. That said,
they tell me they will be doing a release soon, and I bet we could
convince that soon to be before Sage 4.0 releases). Can all of these be
replaced with actual releases for Sage 4.0?
The second is cleaning out ABI-changing patches that Sage has against its
dependencies. For example, there's a Sage patch to NTL written by David
Harvey that I submitted upstream. After a discussion between David Harvey
and the NTL maintainer, upstream added a different API accomplishing the
patch's goal in the 5.5 release. It would be great if Sage were converted
to use NTL 5.5 and that new API for Sage 4.0. The long-term work related
to doing this is quite small if the project submitted all of those patches
upstream as they are committed to Sage.
In my experience pushing Sage patches upstream so far, the original
developers have generally been very helpful with these kinds of issues.
So, I think it is feasible to do both of these things in the next 3 weeks
if we start soon.
-Tim Abbott
On Wed, 22 Apr 2009, mabshoff wrote:
>
> Hello,
>
> while there should be a quick 3.4.2 to mop up patches from trac before
> the big 4.0 jump today we had a planning session during the UW status
> meeting about the goals for Sage 4.0. The result is at
>
> http://wiki.sagemath.org/plan/sage-4.0
>
> It still needs a little polish, i.e. the issues for Solaris as well as
> 64 bit OSX support need to be fleshed out, but the 75% coverage target
> has a lot of concrete projects and/or suggestions on what to attack.
> If anyone has some other suggestions for large projects that are
> doable in the next 3 weeks please let us know.
>
> Cheers,
>
> Michael
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
