On Wed, Jun 24, 2009 at 01:46:29PM -0700, Robert Miller wrote:
On Jun 24, 10:34 pm, Robert Miller rlmills...@gmail.com wrote:
I really like having the ticket number first, it makes it easy to see
(given an ordered list of patches) what patches belong as part of a
single ticket.
Btw: would it be easy to extract from the current automated release
tools a python function that given a ticket number would return the
url's of the corresponding patches on trac?
See the first two functions in $SAGE_ROOT/local/bin/sage-apply-ticket.
-cc
On 2009-Jun-24 13:56:59 -0700, Robert Miller rlmills...@gmail.com wrote:
Another point to make is a video I saw recently by the SVN guys, who
claimed that the amount of discussion which centers around a decision
is inversely proportional to how important it is. They related a story
where the
2009/6/25 Jason Grout jason-s...@creativetrax.com:
Robert Miller wrote:
I think the following is a counterexample to The trac_ prefix does
not bring any useful information.
I still think it's not really, and it is just making the name longer,
but I don't really care either.
I don't see the
On Jun 25, 2009, at 1:37 AM, John Cremona wrote:
2009/6/25 Jason Grout jason-s...@creativetrax.com:
Robert Miller wrote:
I think the following is a counterexample to The trac_ prefix
does
not bring any useful information.
I still think it's not really, and it is just making the name
On Thu, Jun 25, 2009 at 10:48 AM, Robert
Bradshawrober...@math.washington.edu wrote:
On Jun 25, 2009, at 1:37 AM, John Cremona wrote:
2009/6/25 Jason Grout jason-s...@creativetrax.com:
Robert Miller wrote:
I think the following is a counterexample to The trac_ prefix
does
not bring any
William Stein wrote:
On Thu, Jun 25, 2009 at 10:48 AM, Robert
Bradshawrober...@math.washington.edu wrote:
On Jun 25, 2009, at 1:37 AM, John Cremona wrote:
2009/6/25 Jason Grout jason-s...@creativetrax.com:
Robert Miller wrote:
I think the following is a counterexample to The trac_ prefix
On Thu, 25 Jun 2009 at 09:37AM +0100, John Cremona wrote:
I did not know that, which will be useful. What is the canonical
recipe for getting the patch's URL? When I try I sometimes find I
have downloaded some html thing by mistake.
I didn't know that qimport did that either, so I made this
On Thu, Jun 25, 2009 at 02:19:38AM -0700, Jason Grout wrote:
At the bottom of the html view, there's a link entitled original
format which gives the raw patch. It's the same as the html-view
url, but with attachment replaced with raw-attachment.
And it is a major pain to have to find
Jason Grout wrote:
When Mike was experimenting with trac 0.11, he made a plugin or
something that put a raw link next to the attachment link, so an
attachment would look like:
trac_3948_description.patch (raw) Apply on top of previous patches
where clicking on trac_... would bring you
On Thu, Jun 25, 2009 at 02:19:38AM -0700, Jason Grout wrote:
When Mike was experimenting with trac 0.11, he made a plugin or
something that put a raw link next to the attachment link, so an
attachment would look like:
trac_3948_description.patch (raw) Apply on top of previous patches
On Jun 23, 2009, at 4:24 PM, Nicolas M. Thiery wrote:
Indeed. The current trac naming convention really strongly
encouraged
you to do the right thing, which is to always open a trac ticket
for
whatever you're working on.
Definitely. That also why I 100% support having the ticket
I used to include a commit message when I did not use MQs. With MQs I
make the patch using sage -hg export qtip blah.patch and do not
get prompted for a commit message. Thelast one I did then ended up
with [mq]: intpts where the commit message would be, so perhaps that
is the commit
I think the following is a counterexample to The trac_ prefix does
not bring any useful information.
I still think it's not really, and it is just making the name longer,
but I don't really care either.
I don't see the use for it either, but it's not a huge issue for me.
I want to weigh
On Wed, Jun 24, 2009 at 10:20 AM, Craig Citrocraigci...@gmail.com wrote:
I think the following is a counterexample to The trac_ prefix does
not bring any useful information.
I still think it's not really, and it is just making the name longer,
but I don't really care either.
I don't see
On Wed, Jun 24, 2009 at 11:07 AM, Nick Alexanderncalexan...@gmail.com wrote:
Put 'em in a folder, then -- trac/* will pick 'em up. Having tickets
start with a repo name would vastly improve the automerge experience.
+1 to repo_num_desc.patch
Can repo be optional and default to devel/sage?
2009/6/24 Tom Boothby tomas.boot...@gmail.com:
On Wed, Jun 24, 2009 at 11:07 AM, Nick Alexanderncalexan...@gmail.com wrote:
Put 'em in a folder, then -- trac/* will pick 'em up. Having tickets
start with a repo name would vastly improve the automerge experience.
I put mine in a folder
I think the following is a counterexample to The trac_ prefix does
not bring any useful information.
I still think it's not really, and it is just making the name longer,
but I don't really care either.
I don't see the use for it either, but it's not a huge issue for me.
I should
On Jun 24, 10:34 pm, Robert Miller rlmills...@gmail.com wrote:
I really like having the ticket number first, it makes it easy to see
(given an ordered list of patches) what patches belong as part of a
single ticket. E.g.
6201-heegner.patch
6201-referee-fixes.patch
...
+1
Another point to make is a video I saw recently by the SVN guys, who
claimed that the amount of discussion which centers around a decision
is inversely proportional to how important it is. They related a story
where the project nearly forked and many feelings were hurt over
something ten
Robert Miller wrote:
I think the following is a counterexample to The trac_ prefix does
not bring any useful information.
I still think it's not really, and it is just making the name longer,
but I don't really care either.
I don't see the use for it either, but it's not a huge issue for me.
Robert Miller wrote:
I think the following is a counterexample to The trac_ prefix does
not bring any useful information.
I still think it's not really, and it is just making the name longer,
but I don't really care either.
I don't see the use for it either, but it's not a huge issue for me.
That sounds quite sensible to me. Sometimes I make a patch before
opening a ticket, so the patch name does not have the ticket number on
it (e.g. #6386 opened yesterday). But it would not be a bad thing if
I had opened the ticket first (to indicate that I was working on it)
so that I would have
On Tue, Jun 23, 2009 at 10:36 AM, John Cremonajohn.crem...@gmail.com wrote:
That sounds quite sensible to me.
What is that? It sounds below like you're basically arguing for
what we currently do.
Regarding what we currently do, this is not something that is
convention emerging or
2009/6/23 William Stein wst...@gmail.com:
On Tue, Jun 23, 2009 at 10:36 AM, John Cremonajohn.crem...@gmail.com wrote:
That sounds quite sensible to me.
What is that? It sounds below like you're basically arguing for
what we currently do.
I wasn't very clear, sorry. I thought that
On Tue, Jun 23, 2009 at 1:12 PM, John Cremonajohn.crem...@gmail.com wrote:
Then we need conventions for followup patches on tickets (reviewer's
patches and the like). And a convention for whether the reviewer's
patch replaces the original (something all too easy to happen by
mistake when
2009/6/23 William Stein wst...@gmail.com:
On Tue, Jun 23, 2009 at 1:12 PM, John Cremonajohn.crem...@gmail.com wrote:
Then we need conventions for followup patches on tickets (reviewer's
patches and the like). And a convention for whether the reviewer's
patch replaces the original (something
On Tue, Jun 23, 2009 at 11:16:46AM +0200, William Stein wrote:
Regarding what we currently do, this is not something that is
convention emerging or standardization attempt. It's something
that Michael Abshoff standardized on probably 8-10 months ago, and as
far as I know strongly required
28 matches
Mail list logo
