On Thu, 23 Apr 2009, mabshoff wrote:
> I doubt this will ever happen. Soon for example we plan to switch to
> the svn version of pari which absolutely changes lots of things in
> Sage in non-backward compatible ways, so you cannot use the stable
> pari release with Sage any more. And given the timeframe the pari devs
> do releases this does not bode well for stable releases.
Well, how long after Sage switches to this version will it be before a
stable pari release with these features comes out? If we're talking 3-6
months, this isn't a real problem. If Sage were going with doing regular
stable releases, then it would make sense to talk to the pari developers
before upgrading to the SVN version and get a commitment from them that
they'll do a release with those features within the next 3-6 months.
Obviously we have no control over the pari developers so we would not be
able to obtain guarantees, but it seems worth trying to obtain them.
This is probably a good example of the process I would use if I were
managing the stable releases every 3-6 months. When discussion comes up
of upgrading an .spkg to an SVN version, we send a quick note to upstream
asking if they are likely to do a release with the features we need within
the appropriate timescale. Similarly, when we add an ABI-changing patch
against an upstream library, we should immediately send it upstream and
ask whether they can commit to releasing with that functionality in the
next 3 months.
> Also: NTL releases maybe once a year, often less frequent, so the next
> time we change something in the interface there won't be a release for
> some time. While we will upgrade to NTL 5.5 soon I am not sure it will
> be there in time for Sage 4.0.
How often does Sage need to patch a rarely releasing project like NTL?
As far as I'm aware, Sage has only had one ABI-changing patch against NTL
since I started working on Sage in Debian in November 2007. Victor Shoup
is a nice guy, I'm sure that we can convince him to do an extra release
every couple years so that Sage can have its every-N-months major stable
release work with a released version of NTL.
> The problem is that some upstream projects release slowly while others
> are fast and do a point release when we submit a bugfix. One such
> example is FLINT where I get an instant update when we fix something or
> complain about a bug (i.e. see FLINT 1.2.3, 1.2.4, 1.2.5 the last two
> weeks for build issues for example). I don't think there is any
> reasonable way to guarantee that Sage will ship clean upstream every 3
> or 6 months. I am happy to try, but I don't want any rule since fixing
> a bug in Sage takes precedence over packaging concerns for me any day.
> Sorry.
Of course it will be the case that occasionally some upstream is really
slow about releasing, and one has to just give up and move on. As Jason
Grout points out, even Debian runs SVN versions sometimes when upstream is
being really bad about releasing.
But on the other side of this coin, I often find that when I contact a
Sage upstream about a patch Sage has had against their software for
several months that I want merged, they were completely unaware of the
patch's existence. Maybe I've been unlucky in my sampling, but I get the
sense that Sage development does not currently react to merging a new
ABI-changing patch with "we should send this upstream ASAP".
-Tim Abbott
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
