On 2009-Jun-24 13:56:59 -0700, Robert Miller 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 near
> 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 Wed, Jun 24, 2009 at 01:46:29PM -0700, Robert Miller wrote:
>
> On Jun 24, 10:34 pm, Robert Miller 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.
> >
> >
> 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
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 br
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
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 thi
William Stein wrote:
> On Thu, Jun 25, 2009 at 10:48 AM, Robert
> Bradshaw wrote:
>> On Jun 25, 2009, at 1:37 AM, John Cremona wrote:
>>
>>> 2009/6/25 Jason Grout :
Robert Miller wrote:
I think the following is a counterexample to "The trac_ prefix
does
not bring an
On Thu, Jun 25, 2009 at 10:48 AM, Robert
Bradshaw wrote:
>
> On Jun 25, 2009, at 1:37 AM, John Cremona wrote:
>
>> 2009/6/25 Jason Grout :
>>>
>>> Robert Miller wrote:
>>> I think the following is a counterexample to "The trac_ prefix
>>> does
>>> not bring any useful information."
>>>
On Jun 25, 2009, at 1:37 AM, John Cremona wrote:
> 2009/6/25 Jason Grout :
>>
>> 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
2009/6/25 Jason Grout :
>
> 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 us
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 h
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 h
> 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
On Jun 24, 10:34 pm, Robert Miller 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 o
> >> 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.
2009/6/24 Tom Boothby :
>
> On Wed, Jun 24, 2009 at 11:07 AM, Nick Alexander 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
On Wed, Jun 24, 2009 at 11:07 AM, Nick Alexander 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 l
> 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 's
On Wed, Jun 24, 2009 at 10:20 AM, Craig Citro 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 se
>>> 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 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 com
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 messag
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 th
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 requ
2009/6/23 William Stein :
>
> On Tue, Jun 23, 2009 at 1:12 PM, John Cremona 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
>> m
On Tue, Jun 23, 2009 at 1:12 PM, John Cremona 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 fo
2009/6/23 William Stein :
>
> On Tue, Jun 23, 2009 at 10:36 AM, John Cremona 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
On Tue, Jun 23, 2009 at 10:36 AM, John Cremona 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".
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
30 matches
Mail list logo
