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