On May 26, 2010, at 2:06 AM, David Kirkby wrote:
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.
Unless we start accepting spkgs with un-checked in changes, we're
going to require a working mercurial for Sage development in any case.
Learning mercurial is a requirement for developing Sage, there's no
way around that. Personally, I would say anyone not using queues is at
a disadvantage, and they're really easy to pick up (especially if
you're just working on a single patch, rather than popping and pushing
a whole stack).
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.
I know google well :). (Well, I knew it was possible, but forgot the
option.) I especially like long commits when browsing repositories
through the web interface (and on a tangential note, we should be
providing an easier way to brows the source and repositories of the
spkgs online).
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
Given William's reductio ad absurdum argument of using text files to
keep track of the Sage library changes, it's clear that there are
disadvantages of not using the revision control. On the other hand,
even there we're really using trac as a glorified extension of our
revision control to keep the extensive comments.
Personally, I brought this up because it seems redundant to me to
record changes in two places. Which one gets the "good" description? I
hadn't realize some people don't like using mercurial so much.
Here's another idea:
1) A clear description in SPKG.txt how to get the log.
2) We could add a line in SPKG.txt that says "Anything below here will
get added to the commit message on packaging..." and then do so.
Maybe this would just complicate things. I guess I don't feel that
strongly about it, and clearly many people do feel strongly about
using plain text files. I don't edit spkgs enough for it to matter
much to me (other than Cython, where bumping the version is
essentially the only thing I ever do).
- 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
