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. - 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
