2010/2/4 kcrisman <kcris...@gmail.com>:
>
>
>> >> I strongly support this. Judging by how solid my tests are with
>> >> 4.3.2
>> >> already, the 4.3.2 release will definitely be happening this
>> >> Saturday.
>> >> I'm highly impressed with how efficiently Minh is handling the
>> >> 4.3.2
>> >> release cycle.
>>
>> >>> I would really like to see #7876 merged in this release. It is a
>> >>> rather
>> >>> embarrassing bug which has a fix for 2 weeks now. We've already
>> >>> released once without fixing this, even though the patch was
>> >>> available.
>>
>> >>> Unfortunately, the patch there depends on a bunch of other tickets
>> >>> which are fixed by the latest pynac release. The tickets affected
>> >>> are
>> >>> #7822, #6961, #7876, #7363, #7955, #7957, #7916, #6465, and #6559.
>> >>> Of
>> >>> these, #6961, #7363, #6465 and #6559 still needs review.
>>
>> >> I hope people will do these reviews ASAP, so this can all get into
>>
>> > One thing that makes doing these reviews difficult is that each Pynac
>> > spkg is sort of a patch bomb. There are a lot of doctest failures/
>> > segfaults with each update until one applies *all* the patches, and
>> > when there are 5-15 of these (sometimes multiple for a given ticket),
>> > it is difficult to disentangle whether any of them are 'real' at each
>> > stage. I don't feel comfortable loading in all of them at once and
>> > giving a sweeping positive review if we are really supposed to test
>> > and try edge cases for each ticket individually. Doing a good job of
>> > reviewing nine tickets simultaneously could take many hours.
>>
>> > So I propose something which might be dumb, but which I'll throw out
>> > there anyway. Since sagenb and pynac are so integrally bound up with
>> > Sage, would it be possible to have their spkgs automatically keep the
>> > build materials, for trying patches and for sage -b to do changes?
>> > Then one could have
>> > hg_sage
>> > hg_extcode
>> > hg_scripts
>> > hg_pynac
>> > hg_sagenb
>> > or at the very least be able to apply patches one at a time to Pynac
>> > from its tree, see how that changes just the one Sage patch, and move
>> > on from there. Maybe I'm the only person who would be helped by this,
>> > but maybe not.
>>
>> > I understand that the current system obviously works okay, especially
>> > since Burcin clearly has done *more* than the lion's share of this
>> > great work and it is extremely convenient for him. But it also makes
>> > it really hard for new people, or ones who can't spend more than 20-30
>> > minutes at a time on it, to help with this.
>>
>> I just want to say +1 to all of the above--there really needs to be a
>> better way of handling the code (spkgs) that are not under the main
>> revision control, but primarily developed by Sage developers and
>> intimately connected to the Sage library, especially with regards to
>> the referee system. I don't have any easy answers...
>>
>> - Robert
>
> Okay, I will move this discussion to sage-devel then.
>
> For a start, one could have such spkgs (after building) remain in spkg/
> build, as bzip and prereq already inhabit that space. I assume this
> would be possible using sage-spkg, or the spkg install scripts? And
> adding a couple extra things at the bottom of misc/hg.py might fairly
> easily make central revision control possible for that. Or are both
> of these things more subtle than I think?
If you have an spkg foo and type
sage -f -m foo.spkg
then it will not be deleted from spkg/build/ after the install completes.
William
--
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
