On Fri, Oct 22, 2010 at 7:28 AM, Johan S. R. Nielsen <j.s.r.niel...@mat.dtu.dk> wrote: > 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.
Hence http://trac.sagemath.org/sage_trac/ticket/9967 so several tickets can share a single Sage. Of course this only handles patches to the sage library, not spkgs, but that would be a huge step forward already. > 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. At the rate of, what was it, 3-5 new tickets a day, I think that's totally feasible. Especially for a distributed build bot where people can donate their machines (which would also give us a diversity of hardware, specifically testing the hardware that people actually care about). > 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. The actual sage library weighs in at 175M, but the actual number is much smaller due to auto-generated Cython files being hard links (unless they're re-built). (Perhaps we could do better by, say, hard-linking unmodified python files as well if we're careful with the automation? (That might be messy, we'd have to be sure to overwrite not modify them...)) In any case, this times as many to-be-reviewed tickets as there are is within the feasible range, and what I would consider a good use of hardware. I'm certainly imagining a single server serving all tickets--preemptively having them there, if feasible, would IMHO make a huge difference. > 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. Thanks for the enthusiasm. - Robert -- 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
