[sage-devel] Re: patch naming scheme on trac
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. E.g. 6201-heegner.patch 6201-referee-fixes.patch ... +1 If just one could tolerate also a description field before the number, imposing it to be identical for all patches in the ticket, that would do as well. Oh, and if you really want a prefix, sage_... would be more specific than trac_ (many projects use trac) Something occurs to me, which is that the sage-combinat group spends a lot of time working on patches outside of trac. This is probably why Nicolas prefers to have them organized by concept. But for me, I'm always on trac-- everything I work on, even experimental, has a trac ticket. I generally tend to have several tickets open in Firefox so I know which issues I'm tracking. Then I just tab over to the relevant ticket, and that's why trac_### is so useful. Since we are discussing naming conventions for patches which are on trac, maybe we should keep that in mind. Maybe the combinat group can discuss a related scheme, and have conversion tools which make it effortless to swap between the two schemes (I'm not volunteering here, just so nobody gives the usual response :-) ). Oh well, I guess I'll just end up doing this. 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? I'd also like to point out that one of the biggest reasons projects fail is due to trying to change their tools midstream, which is one argument for keeping the convention the way it is. However, that is precisely what the combinat group would have to do to adapt to this scheme. This is why I recommend automated conversion tools. 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 times more trivial than this topic. Just for perspective. Definitely. Speak of pickling for the category stuff ... But yeah I am being grumpy, and mainly needed to express my disagreement a last time, in preparation for the future complaints of our developers about the yet another little grain of complexity of having different patch names on trac and on sage-combinat server. Best, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 project nearly forked and many feelings were hurt over something ten times more trivial than this topic. Just for perspective. By the way, I just rediscovered the video, and the topic was actually whether or not to have spaces before parentheses. They didn't actually almost fork, but there was a vast vote, where people who hadn't contributed for a long time were being lobbied to. Within FreeBSD development circles, this is referred to as a 'bikeshed': The principal is that if someone starts discussing how to build a nuclear reactor containment vessel, very few people will have sufficient understanding of the issues involved to be able to offer constructive comments and so will refrain from commenting at all. OTOH, if someone starts discussing how to build a shed to store their pushbike, everyone will have an opinion on what colour it should be and so everyone makes a comment. As for this specific thread, I think it should be painted green... -- Peter Jeremy pgpLduj7KhBp6.pgp Description: PGP signature
[sage-devel] Re: patch naming scheme on trac
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 use for it either, but it's not a huge issue for me. I should explain my workflow, as I'm probably not the only person doing this (e.g. Craig). When I'm managing releases is one thing, but in daily practice, I always download patches to my home directory. Think about it. Open a terminal, wget a patch, and this is what I presume that you're aware that hg qimport also takes http URLs and automatically downloads a patch and puts it onto the queue? Ever since Carl showed that to me, I don't think I've downloaded any patch with wget. 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. John Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 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 explain my workflow, as I'm probably not the only person doing this (e.g. Craig). When I'm managing releases is one thing, but in daily practice, I always download patches to my home directory. Think about it. Open a terminal, wget a patch, and this is what I presume that you're aware that hg qimport also takes http URLs and automatically downloads a patch and puts it onto the queue? Ever since Carl showed that to me, I don't think I've downloaded any patch with wget. 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. 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. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 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 explain my workflow, as I'm probably not the only person
doing this (e.g. Craig). When I'm managing releases is one thing,
but
in daily practice, I always download patches to my home directory.
Think about it. Open a terminal, wget a patch, and this is what
I presume that you're aware that hg qimport also takes http URLs and
automatically downloads a patch and puts it onto the queue? Ever
since
Carl showed that to me, I don't think I've downloaded any patch
with wget.
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.
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 that link every time you apply
a patch, imho. I hate that. It's a design flaw in trac.
That's why I made
sage: hg_sage.apply('any reasonable url into trac')
work...
William
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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
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 explain my workflow, as I'm probably not the only person
doing this (e.g. Craig). When I'm managing releases is one thing,
but
in daily practice, I always download patches to my home directory.
Think about it. Open a terminal, wget a patch, and this is what
I presume that you're aware that hg qimport also takes http URLs and
automatically downloads a patch and puts it onto the queue? Ever
since
Carl showed that to me, I don't think I've downloaded any patch
with wget.
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.
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 that link every time you apply
a patch, imho. I hate that. It's a design flaw in trac.
That's why I made
sage: hg_sage.apply('any reasonable url into trac')
work...
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 to the html page, and
clicking on raw would give you the raw attachment.
Does anyone (Mike?) know whatever happened to that functionality?
Jason
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 bash
function:
function qimport_sage_patch
{
local HG=hg
local PATCH=$(echo $1 | sed -e 's|/attachment/|/raw-attachment/|')
$HG qimport $PATCH
}
You can right-click on a patch link in trac, select copy, and then do
qimport_sage_patch http://;. You can set HG to sage -hg or
whatever. Put this in your .bashrc and it'll always be available.
You can also use sage_hg_patch or whatever it was that William
suggested. :)
Dan
--
--- Dan Drake dr...@kaist.edu
- KAIST Department of Mathematical Sciences
--- http://mathsci.kaist.ac.kr/~drake
signature.asc
Description: Digital signature
[sage-devel] Re: patch naming scheme on trac
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 that link every time you apply
a patch, imho. I hate that. It's a design flaw in trac.
That's why I made
sage: hg_sage.apply('any reasonable url into trac')
work...
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 to the html page, and
clicking on raw would give you the raw attachment.
+1 !
Nicolas
--
Nicolas M. Thiéry Isil nthi...@users.sf.net
http://Nicolas.Thiery.name/
--~--~-~--~~~---~--~~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 to the html page, and clicking on raw would give you the raw attachment. Does anyone (Mike?) know whatever happened to that functionality? I found http://trac.edgewall.org/ticket/5718 but I'm not sure if the changes are easy to backport. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 where clicking on trac_... would bring you to the html page, and clicking on raw would give you the raw attachment. I want this! I need this! +1^(1000!) --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 number in the patch name. +1 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. Starting the patch name with the ticket number defeats tab completion when sorting through a large number of patches, typically in a mercurial queue. It is a life saver for me to be able to do hg qpop categories-fratab This could perhaps be solved via technical methods, e.g., some improvement to how the tab completion works. If it was only within Sage, yes. But doing this in all shells and file browsers that our developers are using does not quite seem like an option to me. I am not saying our convention is optimal; I was just pointing at it for the record. Actually, for most case, it is indeed too verbose, and we often shorten the description part. But I really do want to insist on having the description *first*. 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 ... I do think every patch should at least include the ticket number and *some* kind of descriptive word/phrase. - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 message provided by MQ. I expect there is a way to change that default? Hi John -- I think you just use the '-e' option to either qnew or qrefresh -- I remember it as e for editor. I learned about it here: http://wiki.sagemath.org/MercurialQueues -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 in with a +1 on letting patches start with trac_. I use it so that patches in a directory on my machine are grouped together -- it's much easier to see them and move them around that way, because then trac_* picks them up. I also use a system similar to John Cremona, it seems -- patches named random_thing.patch are half-finished things, and trac_-descr.patch are ready to get uploaded. (So I can't just use *.patch -- it'll pick up both kinds of patches.) Of course, I'm also +10 on having the ticket number and a short description, as everyone else commented, but that seems to be unanimous on this thread. -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 the use for it either, but it's not a huge issue for me. I want to weigh in with a +1 on letting patches start with trac_. I use it so that patches in a directory on my machine are grouped together -- it's much easier to see them and move them around that way, because then trac_* picks them up. I also use a system similar to John Cremona, it seems -- patches named random_thing.patch are half-finished things, and trac_-descr.patch are ready to get uploaded. (So I can't just use *.patch -- it'll pick up both kinds of patches.) 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 Of course, I'm also +10 on having the ticket number and a short description, as everyone else commented, but that seems to be unanimous on this thread. -cc --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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? There's lots our tools can do that doesn't require having a redundant 'sage' or 'sage- main' or 'devel' at the front. This was a feature never added to - merge, that's all. Yeah, that's fine by me. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 called patches/ And maybe I'm not the only one who doesn't even know what the repo name is! John +1 to repo_num_desc.patch Can repo be optional and default to devel/sage? There's lots our tools can do that doesn't require having a redundant 'sage' or 'sage- main' or 'devel' at the front. This was a feature never added to - merge, that's all. Yeah, that's fine by me. Nick --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 explain my workflow, as I'm probably not the only person doing this (e.g. Craig). When I'm managing releases is one thing, but in daily practice, I always download patches to my home directory. Think about it. Open a terminal, wget a patch, and this is what happens. It's the easiest thing to do, and if everything starts with trac_, then they're all in the same place. And it's only five characters. Every once in a while, when I'm cleaning things out, it's easier to find and delete all the trac patches, which as John points out, is nice, since none of the other (proprietary) patches are killed when I do this. 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 Something occurs to me, which is that the sage-combinat group spends a lot of time working on patches outside of trac. This is probably why Nicolas prefers to have them organized by concept. But for me, I'm always on trac-- everything I work on, even experimental, has a trac ticket. I generally tend to have several tickets open in Firefox so I know which issues I'm tracking. Then I just tab over to the relevant ticket, and that's why trac_### is so useful. Since we are discussing naming conventions for patches which are on trac, maybe we should keep that in mind. Maybe the combinat group can discuss a related scheme, and have conversion tools which make it effortless to swap between the two schemes (I'm not volunteering here, just so nobody gives the usual response :-) ). I'd also like to point out that one of the biggest reasons projects fail is due to trying to change their tools midstream, which is one argument for keeping the convention the way it is. However, that is precisely what the combinat group would have to do to adapt to this scheme. This is why I recommend automated conversion tools. 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 times more trivial than this topic. Just for perspective. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 times more trivial than this topic. Just for perspective. By the way, I just rediscovered the video, and the topic was actually whether or not to have spaces before parentheses. They didn't actually almost fork, but there was a vast vote, where people who hadn't contributed for a long time were being lobbied to. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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. I should explain my workflow, as I'm probably not the only person doing this (e.g. Craig). When I'm managing releases is one thing, but in daily practice, I always download patches to my home directory. Think about it. Open a terminal, wget a patch, and this is what happens. It's the easiest thing to do, and if everything starts with trac_, then they're all in the same place. And it's only five characters. Every once in a while, when I'm cleaning things out, it's easier to find and delete all the trac patches, which as John points out, is nice, since none of the other (proprietary) patches are killed when I do this. +1 Jaap 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 --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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. I should explain my workflow, as I'm probably not the only person doing this (e.g. Craig). When I'm managing releases is one thing, but in daily practice, I always download patches to my home directory. Think about it. Open a terminal, wget a patch, and this is what I presume that you're aware that hg qimport also takes http URLs and automatically downloads a patch and puts it onto the queue? Ever since Carl showed that to me, I don't think I've downloaded any patch with wget. Jason --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 had the number available when creating the patch. I like to be able to clear out all the patches which lie around on various computers. I know that any patch with a trac number on it will exist on trac so can be deleted; anything without a number is more likely to be some work inprogress which I have saved from one Sage build to carry on with on another, so I tend not to delete those. John 2009/6/23 Nicolas M. Thiery nicolas.thi...@u-psud.fr: Dear all, Apparently, there is a convention emerging to name systematically all patches on trac as trac__description.patch. I very much value this standardization attempt, especially in a period where things are getting automatized. We need it! In particular, I find it very useful to include the trac ticket number. On the other hand, let me argue about some inconveniences of the current naming scheme: - The trac_ prefix does not bring any useful information. - Starting the patch name with the ticket number defeats tab completion when sorting through a large number of patches, typically in a mercurial queue. It is a life saver for me to be able to do hg qpop categories-fratab Thoughs? For the record, here is the naming scheme we use in Sage-Combinat: the_theme-the_description-ticket_number-author_initials.patch example: categories-freemodule-6136-nt.patch Best, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 standardization attempt. It's something that Michael Abshoff standardized on probably 8-10 months ago, and as far as I know strongly required (at least, I remember getting a *lot* of complaints from him and others when I didn't use that convention). I personally had another convention, which was: reponame-tracnumber-description_of_it.patch Having been convinced by Michael and others many many months ago to switch to trac_tracnumber-description_of_it.patch, even though I didn't personally find it optimal, I now think we should continue with this standard, since it does seem to work well in practice. 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 had the number available when creating the patch. 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. I think the following is a counterexample to The trac_ prefix does not bring any useful information. I like to be able to clear out all the patches which lie around on various computers. I know that any patch with a trac number on it will exist on trac so can be deleted; anything without a number is more likely to be some work inprogress which I have saved from one Sage build to carry on with on another, so I tend not to delete those. John Starting the patch name with the ticket number defeats tab completion when sorting through a large number of patches, typically in a mercurial queue. It is a life saver for me to be able to do hg qpop categories-fratab This could perhaps be solved via technical methods, e.g., some improvement to how the tab completion works. William 2009/6/23 Nicolas M. Thiery nicolas.thi...@u-psud.fr: Dear all, Apparently, there is a convention emerging to name systematically all patches on trac as trac__description.patch. I very much value this standardization attempt, especially in a period where things are getting automatized. We need it! In particular, I find it very useful to include the trac ticket number. On the other hand, let me argue about some inconveniences of the current naming scheme: - The trac_ prefix does not bring any useful information. - Starting the patch name with the ticket number defeats tab completion when sorting through a large number of patches, typically in a mercurial queue. It is a life saver for me to be able to do hg qpop categories-fratab Thoughs? For the record, here is the naming scheme we use in Sage-Combinat: the_theme-the_description-ticket_number-author_initials.patch example: categories-freemodule-6136-nt.patch Best, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 Nicolas made some good points but did not go through them one by one as I was leaving for a meeting... 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 (at least, I remember getting a *lot* of complaints from him and others when I didn't use that convention). I personally had another convention, which was: reponame-tracnumber-description_of_it.patch Having been convinced by Michael and others many many months ago to switch to trac_tracnumber-description_of_it.patch, even though I didn't personally find it optimal, I now think we should continue with this standard, since it does seem to work well in practice. 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 had the number available when creating the patch. 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. So that's an argument for having a ticket number as part of every patch which his uploaded to trac. I think the following is a counterexample to The trac_ prefix does not bring any useful information. I like to be able to clear out all the patches which lie around on various computers. I know that any patch with a trac number on it will exist on trac so can be deleted; anything without a number is more likely to be some work inprogress which I have saved from one Sage build to carry on with on another, so I tend not to delete those. Not quite, since having the ticket number anywhere in the patch name would do that. Nicolas wanted it later in the name, replacing the trac_ prefix with something more descriptive. One thing I did not like about Nicolas's scheme was that trac names become rather long. 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 using MQs, at least for me) or is to be applied after the original. The latter makes it easier for the original patcher to see what the reviewer wants changing; the former makes it easier for others to apply the patch(es). In many cases the reviewer does not make any new patches, just suggests what might or should be changed (more like a referee's report on an academic paper). In other cases there is more of a dialogue between original patcher and reviewer, ending up with a collaborative effort. I think that can be quite productive. John John Starting the patch name with the ticket number defeats tab completion when sorting through a large number of patches, typically in a mercurial queue. It is a life saver for me to be able to do hg qpop categories-fratab This could perhaps be solved via technical methods, e.g., some improvement to how the tab completion works. William 2009/6/23 Nicolas M. Thiery nicolas.thi...@u-psud.fr: Dear all, Apparently, there is a convention emerging to name systematically all patches on trac as trac__description.patch. I very much value this standardization attempt, especially in a period where things are getting automatized. We need it! In particular, I find it very useful to include the trac ticket number. On the other hand, let me argue about some inconveniences of the current naming scheme: - The trac_ prefix does not bring any useful information. - Starting the patch name with the ticket number defeats tab completion when sorting through a large number of patches, typically in a mercurial queue. It is a life saver for me to be able to do hg qpop categories-fratab Thoughs? For the record, here is the naming scheme we use in Sage-Combinat: the_theme-the_description-ticket_number-author_initials.patch example: categories-freemodule-6136-nt.patch Best, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this
[sage-devel] Re: patch naming scheme on trac
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 using MQs, at least for me) or is to be applied after the original. Let's form a committee. :-) I'm worried about this being too complicated to easily remember and teach people. That might turn off new developers, who are the most important resource to the Sage project. The latter makes it easier for the original patcher to see what the reviewer wants changing; the former makes it easier for others to apply the patch(es). Just for the record, I really don't like the former. I reallly like when I can see each step in a code conversation between reviewer and author as a sequence of patches. In many cases the reviewer does not make any new patches, just suggests what might or should be changed (more like a referee's report on an academic paper). In other cases there is more of a dialogue between original patcher and reviewer, ending up with a collaborative effort. I think that can be quite productive. Yes, I greatly prefer that. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 all too easy to happen by mistake when using MQs, at least for me) or is to be applied after the original. Let's form a committee. :-) I'm worried about this being too complicated to easily remember and teach people. That might turn off new developers, who are the most important resource to the Sage project. Good point. The latter makes it easier for the original patcher to see what the reviewer wants changing; the former makes it easier for others to apply the patch(es). Just for the record, I really don't like the former. The perhaps we should officially disapprove of it. As I said, it's usually down to a mistake (forgetting the hg -qnew step), at least in my case. John I reallly like when I can see each step in a code conversation between reviewer and author as a sequence of patches. In many cases the reviewer does not make any new patches, just suggests what might or should be changed (more like a referee's report on an academic paper). In other cases there is more of a dialogue between original patcher and reviewer, ending up with a collaborative effort. I think that can be quite productive. Yes, I greatly prefer that. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: patch naming scheme on trac
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 (at least, I remember getting a *lot* of complaints from him and others when I didn't use that convention). I saw that Michael was using this convention internally. But I never got any request for this as an external convention until yesterday (it's not like I did not post any patch). And I far as I know, it is not documented anywhere. Or is it? (I asked and was told to add it myself, hence this thread). Having been convinced by Michael and others many many months ago to switch to trac_tracnumber-description_of_it.patch, even though I didn't personally find it optimal, I now think we should continue with this standard, since it does seem to work well in practice. Is there any infrastructure relying deeply on it? 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 number in the patch name. 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. Starting the patch name with the ticket number defeats tab completion when sorting through a large number of patches, typically in a mercurial queue. It is a life saver for me to be able to do hg qpop categories-fratab This could perhaps be solved via technical methods, e.g., some improvement to how the tab completion works. If it was only within Sage, yes. But doing this in all shells and file browsers that our developers are using does not quite seem like an option to me. I am not saying our convention is optimal; I was just pointing at it for the record. Actually, for most case, it is indeed too verbose, and we often shorten the description part. But I really do want to insist on having the description *first*. Cheers, Nicolas -- Nicolas M. Thiéry Isil nthi...@users.sf.net http://Nicolas.Thiery.name/ --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
