On Wed, Dec 1, 2010 at 9:57 AM, Robert Bradshaw <rober...@math.washington.edu> wrote: > On Wed, Dec 1, 2010 at 9:40 AM, John Cremona <john.crem...@gmail.com> wrote: >> On Wed, Dec 1, 2010 at 5:28 PM, pang <pablo.ang...@uam.es> wrote: >>> On 1 dic, 17:40, David Kirkby <david.kir...@onetel.net> wrote: >>>>. But for someone that regularly submits tickets, if they can't be bothered >>>> to test them, then I'm personally not going to spend much time on a ticket. >>> >>> ok, we got each other wrong. The way I understood Robert Bradshaw's >>> comment is: "the reviewer should spend his time reading the code, not >>> testing on any possible platform", and I heartly agreed. I even got >>> carried away and thought he was suggesting using buildbot to automate >>> the procedure, so that the reviewer could miss some of the long, >>> tedious and troublesome problems of reviewing. >>> >>> But I agree it is very unpolite to submit a ticket without doing the >>> testing yourself. >>> >> >> I think we should lighten up just a little. (Of course I do agree >> that proper testing is important!) >> >> Many people who write patches for Sage do their testing on machines >> which either have only one or two processors, or are heavily loaded, >> or both. This was true for me for most of the last 3 years. Then, >> the testing I would do before submitting a patch would often be >> limited to the file I was patching, or the directory that file was in, >> and maybe some other files which I could tell might be affected. >> Testing the whole library very time took several hours and that was >> just not practical. More recently I can use a machine with 24 >> processors which is exclusively for my research group and so far very >> underused (this will change -- I just gave Robert Miller an account!) >> so I can do "sage -tp 30 -long" and it still only takes 10 minutes to >> test the whole library, so I do. > > +1 > > Authors have the responsibility of testing their code, to a reasonable > degree at least (and what is reasonable may depend on the hardware > they have available, the magnitude of their change, etc.) but my point > is that it's not the *reviewers* job to test the code (assuming it can > be verified that the tests pass). > >> But I am not going to be rude to anyone who submits a patch without >> noticing that it causes some test to fail in some other part of the >> library which they have never heard of! > > I completely agree. And with quick, automated feedback they can go and > take care of anything they missed rather than wait two weeks and a > release cycle later to see that some corner case was missed that > affected a doctest far away and now they need a tiny fix + rebase + > context switch to re-upload the new patch, as well as the reviewers > time being wasted.
On this note: http://sage.math.washington.edu:21100/ticket/ -- 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
