> >> 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? - kcrisman -- 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
