Cleaning up a patch and giving it to the user sounds fine to me. But it's a 
different matter to create a sage command which automatically doctests and 
submits patches. That's going too far, IMO. It's nice to allow developers 
to stay away from the details as much as possible, which lowers the barrier 
to entry, and certainly an intimate understanding of version control is not 
really a necessary trait in a competent Sage developer, which I guess 
justifies stuff like the hg_*() commands.

But surely assuming a developer's ability to type `make ptestlong` on the 
command line and to upload a file to a website is not a particularly high 
hurdle? At some point the effort required to learn how to use Sage's easy 
wrapper around a procedure becomes about as much as the effort required to 
learn how to do the procedure directly, even though the former only enables 
you to do Sage development better, whereas the latter often enables you to 
do general development better. Personally I think the hg_*() commands are 
pretty close to that line, and automatic doctesting and uploading of 
patches go over it. But of course I could be wrong.

-Keshav

----
Join us in #sagemath on irc.freenode.net !

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

Reply via email to