On 2/7/12 2:46 PM, William Stein wrote:
On Tue, Feb 7, 2012 at 12:28 PM, Jason Grout
<jason-s...@creativetrax.com> wrote:
On 2/7/12 2:16 PM, Robert Bradshaw wrote:
On Tue, Feb 7, 2012 at 12:08 PM, William Stein<wst...@gmail.com> wrote:
On Tue, Feb 7, 2012 at 12:00 PM, Simon King<simon.k...@uni-jena.de>
wrote:
Hi William,
On 7 Feb., 20:47, William Stein<wst...@gmail.com> wrote:
It's important (in fact, critical) that the trac ticket number is
clearly available in the commit message. But having it twice in two
different ways in almost every message seems a little bit sloppy to
me.
We were told, by different release managers, that the commit message
has to identify the ticket number. Patches not following the rule were
rejected.
If that rule has changed in the meantime, the new rule ("Do not
mention the ticket number in your commit message!") should be enforced
in the same way as the old rule was enforced.
I think the commit message should mention the ticket number. This
makes it much easier to keep track of stuff, even before the release
manager puts the code in Sage. E.g., I have a big patch queue of my
own code, and I find the ticket numbers in commit messages useful.
What I'm suggesting is that the script that auto-adds ticket numbers
should strip the user-added ticket number first, to avoid extensive
duplication.
Or at the very least not add it if it's not already there. (Stripping
it in all its variants might be hard.)
On the other hand, I think the canonical number should be the automatically
prepended number, and that the prepended number should *always* be added:
Are you arguing that this from "hg log" is a good commit message?
summary: Trac #6804: Trac #6804: change '=' to '>=' in the
docstring for Permutation.weak_excedences()
Given the choice between unreliable and inconsistently formatted ticket
numbers that require manual maintenance, compared to automatic, correct,
and consistent numbers, I'd choose the latter, even if it meant that
sometimes the number is duplicated.
I would rather the script try to strip out the ticket number if it
already exists, replacing it with a properly formatted automatically
generated ticket number, rather than trying to decide whether to prepend
the ticket number. In other words, I think the final commit message
should contain an automatically-generated, consistently formatted ticket
number.
My post was more about advocating the opposite of Robert's suggestion
(i.e., I think we should always prepend, and decide whether you should
strip out the existing number), than arguing against making the script
smarter.
1. Its format is consistent, so we can write scripts and things that take
advantage of that consistency
2. It's guaranteed to be correct, i.e., to reflect what ticket the patch was
actually pulled from (in case patches move from ticket to ticket or the user
makes a mistake).
When I do hg log with my patches, I get output like this:
changeset: 16483:722b00d2890c
tag: trac-12229-manifest.patch
user: Jason Grout<jason.gr...@drake.edu>
date: Mon Jan 16 15:13:16 2012 -0600
summary: Patch MANIFEST.in to copy the .inc and .png sagenb doc files
Notice that the "tag" field gives the filename. That's a great place to put
the ticket number (in the filename). You then see the ticket number when
you do hg queues commands, you see it in hg log, you see it in the patches
directory, you see it on trac and when uploading, etc. The summary does not
contain the ticket number---that is added when the ticket is merged.
If I then qfinish the patch, that tag vanishes, right? At least if I
simply import the patch then it vanishes.
Good question. I operate under the assumption that a developer never
qfinishes a patch; it's the release manager's job to commit the patch.
I don't know what happens when you qfinish the patch. Obviously the
release manager script isn't run in that case.
Jason
--
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
