On 10/22/2010 12:20 PM, Robert Bradshaw wrote: > Given the difficulty of finding reviewers, are you arguing we > shouldn't try to make things even easier? Yes, it's not to bad ([copy > the url, qimport, qpush] * n, build, test, run doctests, qpop, ...), > but could be a lot better. Oh, and by "test" I mean not doctests, but > interactively test, where it's more of a pain to context switch and > wait for the build to complete. I'd rather be reading the code and say > "hmm... I wonder if this works..." and just try it out.
This has annoyed me on more than one occasion. Can any trac gurus speak to the possibility of adding two fields to trac tickets? 1) Patches to be applied for the current ticket 2) Tickets on which this patch depends It seems to me that if we had machine-readable fields of this type, it would be possible (easy?) to write a shell script where one would write $ test_ticket #1234 and the script would a) Download and apply the appropriate patches to a mercurial queue b) Build and run the patched version for interactive testing c) Clone the patched version, run all tests, email me the tail of the test log and delete the cloned version. (Works in a clone so I can review other tickets while this is going on.) This little bit of automation would make me a much more productive reviewer, I think. But getting the collection of patch URLs is currently too hard to automate. -Jason -- 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
