On Apr 23, 10:57 pm, Tim Abbott <tabb...@mit.edu> wrote:
> 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?
No clue, there are usually several years between stable pari releases
and so far I don't think there has been anyone able to change their
mind to have something more regular/often.
> 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.
Well, we can try. But the whole point is that is someone posts a pari-
svn.spkg which fixes bugs in functions Sage does not use and adds
functionality that is asked for by people no one will be willing to
wait 3 or 6 months to merge that. It might be more feasible to just
package Sage before that change and then hope in the next couple
months upstream will release.
> 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.
Well, you pushed patches upstream that contain GNUisms and I will end
up patching it out of the sources again, so I am not too happy about
that since upstream way too often does not understand that GNUisms are
bad or are totally unaware of the problem in the first place.
> > 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.
I don't know of any patch but the NTL one where this could be the
case. We have contacted Victor Shoup several times to speak or visit a
Sage days and he has *never* responded. The author of that patch works
at NYU, i.e. the same place as Victor and if he never got around to
get the patch merged than I can hardly call that our fault.
Another author we have contacted via numerous people as well as
multiple times is the cddlib author and he has also *never* responded
to us.
> 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".
I consider this completely wrong. Can you mention some concrete
examples?
> -Tim Abbott
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
-~----------~----~----~----~------~----~------~--~---
