On Oct 22, 10:49 am, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > On 2010-10-21 06:33, Robert Bradshaw wrote: > > > Finally, we need more automation. Refereeing code shouldn't > > have to involve downloading and applying patches and running all > > tests--that should all be done automatically (with failing tickets > > bounced right away, or at least in a 24-48 hour window). We should > > have a notebook server with sessions of Sage with various tickets > > already applied for quick refereeing (or a CLI interface on, say, > > boxen for those who prefer that--"telnet/ssh > > 10921.sage.math.washington.edu" would be cool, opening you immediately > > into a jailed sage session). I'll plug > >http://trac.sagemath.org/sage_trac/ticket/9967which is a requirement > > for this and I just recently started to write a per-ticket build bot. > > This would help close the gap and lag between writing code and getting > > it into Sage, and I think that having such a small gap was one of the > > key ingredients in letting Sage explode like it did. > > I'm afraid your solution is not very scalable. I don't think it's > realistic to have a large number of independent notebook servers with > various tickets. I think an automated system to do doctests is > possible, but if you want also to log in and try things you need many > independent Sage setups. If each one takes several gigabytes, that > looks not practical. > > Jeroen.
I think the idea is extremely beautiful! There are two things: having a set of notebook servers trying out all awaiting_review patches on the latest release for simply successful patching and compiling is very doable (and would be a big help!). Doing actual full doctest of course requires more computer power, but perhaps with neat things like checking many patches in one full doctest, and then only checking each individual patch if there were errors would reduce this. The second thing: giving access to a notebook with a given patch applied is perhaps more futuristic; however, that would make me much more productive and willing to review many patches. It could be done in a modest form with a smaller number of notebook servers and a sort of registration system (next tuesday at 2pm, I'd like to test Trac #10889). Perhaps a long-term goal for Sage is a system which allows a Sage installation to be run in parallel, each branch with its own patches applied but with a smaller overhead (my first idea is using a huge number of symlinks linking to the files the different branches have in common, but that's just off the top of my head). First step is #9976 as Robert was talking about. If we started thinking about these things, we might be able to come up with something good. It can't be hard to beat what is currently there. Cheers, Johan -- 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
