I've started the script I've written about in the previous mail. Now every 6 hours all open mergeable pull requests that are not tested will be tested in python 2.7.1.
The computer I'm using will continue to do the tests unless there is a hardware problem (which is possible as there are some faulty components in it) Stefan On 3 December 2011 16:13, Matthew Rocklin <mrock...@gmail.com> wrote: > It looks like shining panda gives one hour per day free to foss projects. > Is this sufficient for our needs? Or rather, how much compute time would a > nice testing system require? > > > On Sat, Dec 3, 2011 at 8:57 AM, Aaron Meurer <asmeu...@gmail.com> wrote: > >> I went ahead and registered for the Shining Panda thing, since it was >> free. There apparently is a waiting list for the free open source >> plan, and we are number 6. I'll let you know when it goes online. >> >> Aaron Meurer >> >> On Sat, Dec 3, 2011 at 7:53 AM, Aaron Meurer <asmeu...@gmail.com> wrote: >> > The biggest problem with Jenkins in my opinion is that it has such a >> > terrible user interface. >> > >> > SymPy-Bot is nice in that it allows completely distributed testing. >> > The script is so simple and self-contained that anyone can just clone >> > it and run it (I guess there are a few Python dependencies to install, >> > but we could probably make distribute do that work for us too if we >> > wanted). >> > >> > And testing pull requests is way more important than testing master; >> > this is attested to by the fact that we still have not implemented >> > master testing in sympy-bot. In some ways, testing pull requests >> > tests master as a side effect, because we always merge with master >> > first. In fact, the only time I run tests on master directly is when >> > doing a release, and even that's technically some branch. (Don't get >> > me wrong, though; testing master is important, and we should be doing >> > it). >> > >> > This is kind of analogous to the git/GitHub pull request model where >> > you review code before pushing it in and the >> > svn/<svn_review_tool_here> model, where you review it after it goes >> > in. It's pretty clear to me, and I think most others who use GitHub >> > pull requests, that the former is the superior way of doing things. >> > >> > Aaron Meurer >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To post to this group, send email to sympy@googlegroups.com. >> To unsubscribe from this group, send email to >> sympy+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/sympy?hl=en. >> >> > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To post to this group, send email to sympy@googlegroups.com. > To unsubscribe from this group, send email to > sympy+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/sympy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to sympy@googlegroups.com. To unsubscribe from this group, send email to sympy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
