Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-10-09 12:54
Message: This sounds great, I'll include it in Pd-extended and we'll see how it does there. The only problem is that there are two patches included in this tracker and they seem to have the same name. Could you delete the older one, so there is only one patch?
I've done as you asked, though I don't see the reason it was necessary to do so. Files seem to be listed in reverse chronological order of upload, so it's always apparent what the most recent version of a file is from the page layout. If in doubt, you can snoop the URLs and look for the attachment ids, though I'd just grab the topmost link. (The JIRA install at Apache works the same way, and that's how we handle multiple uploads with the same name.) Is there something I've missed?
Since the preferred method of patch submission is "git format-patch", the filename doesn't change unless either the first line of the commit changes or the submitter manually appends a version to it. I can do that, but it's an extra step.
Marvin Humphrey
On Oct 9, 2011, at 6:40 PM, Marvin Humphrey wrote:
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2011-10-09 12:54
Message: This sounds great, I'll include it in Pd-extended and we'll see how it does there. The only problem is that there are two patches included in this tracker and they seem to have the same name. Could you delete the older one, so there is only one patch?
I've done as you asked, though I don't see the reason it was necessary to do so. Files seem to be listed in reverse chronological order of upload, so it's always apparent what the most recent version of a file is from the page layout. If in doubt, you can snoop the URLs and look for the attachment ids, though I'd just grab the topmost link. (The JIRA install at Apache works the same way, and that's how we handle multiple uploads with the same name.) Is there something I've missed?
Since the preferred method of patch submission is "git format- patch", the filename doesn't change unless either the first line of the commit changes or the submitter manually appends a version to it. I can do that, but it's an extra step.
Most Pd people using the SF tracker aren't aware of its details, (I guess me included since I didn't know the order). I think it makes a lot more transparent if there is only one copy of the files there, unless there is a specific reason to have both copies of the patch there, like two different approaches.
You don't need to change the name of the patch at all, IMHO, just deleting old copies is enough to make it clear, in combo with the comments.
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Sun, Oct 09, 2011 at 07:52:34PM -0400, Hans-Christoph Steiner wrote:
Most Pd people using the SF tracker aren't aware of its details, (I guess me included since I didn't know the order).
Come to think of it, JIRA makes this more obvious by graying out the links on all the older files.
I think it makes a lot more transparent if there is only one copy of the files there, unless there is a specific reason to have both copies of the patch there, like two different approaches.
In this particular case, there was a bug in the first patch which was corrected in the second. I was hesitant to remove the first because I figured committer review would be easier if you could see how the two patches had changed.
Then the third patch obsoleted both of them by being faster, correct (as far as I can tell, better than patch 1 at least), and easier to grok. It does take a different approach, particularly in u8_charnum(), and that contrast has been lost. But oh well.
Marvin Humphrey
-
Hans-Christoph Steiner -
Marvin Humphrey