On 25 May 2010 20:58, Robert Bradshaw <rober...@math.washington.edu> wrote: > On May 25, 2010, at 12:35 PM, kcrisman wrote: >> SPKG.txt version >> >> === r-2.10.1.p0 (David Kirkby, February 16th 2010) ===
<Snip lots of stuff I wrote in an SPKG.txt file> >> Are you really suggesting that the commit message should be this >> long? Maybe they should be! > > Yes, I've got no problem with long commit messages, the more info the better > (especially for obscure build files and configure scripts, where the changes > are far from self documenting). There are some nice commit messages in the > combinat code too. If one is a Mercurial guru, then making long commit messages, changing them when one makes a mistake, finding out what someone else has done might all be pretty easy to you. But a simple text file is going to be a lot less intimidating for some (many?). In order to change the contents of the commit message one is going to need to know about queues I expect, since one will probably need to push/pop commit messages. I don't know what's involved. I've personally been happy with the long SPKG.txt, a short commit message. I usually edit SPKG.txt a few times, correct a few errors, then make a final small commit message, which I often make the trac number and trac title, though I'm not very rigid about this. Using Sage to fire up 'hg' is fine if Sage has built to that point, but its not a lot of use if you are trying to debug a problem occurring before Mercurial has been built. If one makes the argument that people should have Mercurial installed, then I don't see the point in having it a standard package. >> And I reiterate that I recall somewhere a suggestion on sage-devel >> that commit messages should be one line long. Does no one else >> remember that? Or did it mean it should not have any carriage >> returns, but be as long as it wants (in which case this was not clear >> at all)? > > Only the first line shows up by default so it should be self-contained and > concise (so that the listings are short). hg log -v will show long commit > messages, and hg log -p will print out the patches as well. > > - Robert Again, you know this, since you know Mercurial well. It was only a few months ago that I put a two or three line commit message and Ming (who is clearly very competent) said only the first line would be recorded. Someone (perhaps you) corrected him. I think there are two things to consider here: 1) What is technically possible with Mercurial 2) What will be understandable by a large fraction of Sage developers. I suspect (2) is a small subset of (1), so having a simple text file, and making the process as simple as possible, is useful. When I first started developing on Sage, I did not know Mercurial. I would makes the changes to the code, update SPKG.txt and get the release manager to update the repository. I suspect requiring informative commit messages will add to the complexity of this. But if the change is made, I wont think it the worst possible crime, but I'd certainly prefer the current simple text file Dave -- 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
