Hi All, The issue tracking discussion seems to have died. Since github issues looks to be a viable alternative at this point, I propose to turn it on for the numpy repository and start directing people in that direction. Thoughts? Chuck
On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
Hi All,
The issue tracking discussion seems to have died. Since github issues looks to be a viable alternative at this point, I propose to turn it on for the numpy repository and start directing people in that direction.
Thoughts?
Sounds good, as long as we don't create duplicates or do something to make the conversion from Trac harder. Ralf
On Mon, Jun 4, 2012 at 9:34 AM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi All,
The issue tracking discussion seems to have died. Since github issues looks to be a viable alternative at this point, I propose to turn it on for the numpy repository and start directing people in that direction.
Thoughts?
Sounds good, as long as we don't create duplicates or do something to make the conversion from Trac harder.
I looked into this a bit, and it looks like the first task is to set up labels. They should probably track what we currently have for trac in order to make moving some (all?) of the tickets over. I'm thinking component, priority, type, milestone, and version, omitting the keywords. I'm not sure how we should handle attachments. Chuck
On Mon, Jun 4, 2012 at 6:05 PM, Charles R Harris <charlesr.harris@gmail.com>wrote:
On Mon, Jun 4, 2012 at 9:34 AM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi All,
The issue tracking discussion seems to have died. Since github issues looks to be a viable alternative at this point, I propose to turn it on for the numpy repository and start directing people in that direction.
Thoughts?
Sounds good, as long as we don't create duplicates or do something to make the conversion from Trac harder.
I looked into this a bit, and it looks like the first task is to set up labels. They should probably track what we currently have for trac in order to make moving some (all?) of the tickets over. I'm thinking component, priority, type, milestone, and version, omitting the keywords. I'm not sure how we should handle attachments.
Version can be left out I think, unless someone finds it useful. We can think about extra labels too. I'd like "easy-fix", as a guide for new contributors to issues to get started on. Ralf
There is an interesting project called http://huboard.com/ The projects suggests using a few Column Labels that provides a nice card-based window onto the Github issues. I have turned on issue tracking and started a few labels. Feel free to add more / adjust the names as appropriate. I am trying to find someone who can help manage the migration from Trac. I have two people but they are both quite inexperienced, and it will take them some time to learn the process. If anyone out there is in a position to spend a month, there are resources available to do the migration. I think this is ideal for someone just getting started in the NumPy community who knows something about web-apis and data-bases (or is eager to learn). Best, -Travis On Jun 4, 2012, at 11:40 AM, Ralf Gommers wrote:
On Mon, Jun 4, 2012 at 6:05 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Mon, Jun 4, 2012 at 9:34 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris <charlesr.harris@gmail.com> wrote: Hi All,
The issue tracking discussion seems to have died. Since github issues looks to be a viable alternative at this point, I propose to turn it on for the numpy repository and start directing people in that direction.
Thoughts?
Sounds good, as long as we don't create duplicates or do something to make the conversion from Trac harder.
I looked into this a bit, and it looks like the first task is to set up labels. They should probably track what we currently have for trac in order to make moving some (all?) of the tickets over. I'm thinking component, priority, type, milestone, and version, omitting the keywords. I'm not sure how we should handle attachments.
Version can be left out I think, unless someone finds it useful.
We can think about extra labels too. I'd like "easy-fix", as a guide for new contributors to issues to get started on.
Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant <travis@continuum.io> wrote:
I have turned on issue tracking and started a few labels. Feel free to add more / adjust the names as appropriate. I am trying to find someone who can help manage the migration from Trac.
Are the github issues set up sufficiently for Trac to be disabled and github to take over? Ray Jones
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones <thouis@gmail.com>wrote:
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant <travis@continuum.io> wrote:
I have turned on issue tracking and started a few labels. Feel free to add more / adjust the names as appropriate. I am trying to find someone who can help manage the migration from Trac.
Are the github issues set up sufficiently for Trac to be disabled and github to take over?
You lost me here. You were going to set up a test site where we could see the Trac --> Github conversion could be tested, before actually pushing that conversion to the numpy Github repo. If you sent a message that that was ready, I must have missed it. The current state of labels on https://github.com/numpy/numpy/issues is also far from complete (no prios, components). Ralf
On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant <travis@continuum.io> wrote:
I have turned on issue tracking and started a few labels. Feel free to add more / adjust the names as appropriate. I am trying to find someone who can help manage the migration from Trac.
Are the github issues set up sufficiently for Trac to be disabled and github to take over?
You lost me here. You were going to set up a test site where we could see the Trac --> Github conversion could be tested, before actually pushing that conversion to the numpy Github repo. If you sent a message that that was ready, I must have missed it.
The current state of labels on https://github.com/numpy/numpy/issues is also far from complete (no prios, components).
I wasn't completely clear. What I meant to ask: "Are the github issues (and labels) set up well enough for Trac to be disabled for accepting new bugs and to point users filing new bugs to github instead?" (The answer to which is "no", based on your reply). I was under the impression that github issues could become the default for new bugs even before the old bugs were moved, but perhaps I misunderstood. I can see arguments for and against this. The primary argument in favor is that it would be easier to transition old bugs to a known set of labels, rather than trying to define the labels at the same time as moving the bugs. (This is more a concern on my part about stepping on toes than a difficulty in knowing what labels are needed, though.) Ray Jones
On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones <thouis@gmail.com>wrote:
On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant <travis@continuum.io> wrote:
I have turned on issue tracking and started a few labels. Feel free
add more / adjust the names as appropriate. I am trying to find someone who can help manage the migration from Trac.
Are the github issues set up sufficiently for Trac to be disabled and github to take over?
You lost me here. You were going to set up a test site where we could see the Trac --> Github conversion could be tested, before actually pushing
to that
conversion to the numpy Github repo. If you sent a message that that was ready, I must have missed it.
The current state of labels on https://github.com/numpy/numpy/issues is also far from complete (no prios, components).
I wasn't completely clear. What I meant to ask:
"Are the github issues (and labels) set up well enough for Trac to be disabled for accepting new bugs and to point users filing new bugs to github instead?"
(The answer to which is "no", based on your reply).
I don't think it's a problem that a few issues have already been filed on Github, but we'll have to properly label them by hand later. Making Github the default or only option now would be a bit strange. It would be better to first do the conversion, or at least have it far enough along that we have agreed on workflow and labels to use. Ralf
I was under the impression that github issues could become the default for new bugs even before the old bugs were moved, but perhaps I misunderstood. I can see arguments for and against this. The primary argument in favor is that it would be easier to transition old bugs to a known set of labels, rather than trying to define the labels at the same time as moving the bugs. (This is more a concern on my part about stepping on toes than a difficulty in knowing what labels are needed, though.)
Ray Jones _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Jun 23, 2012 at 11:13 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant <travis@continuum.io> wrote:
I have turned on issue tracking and started a few labels. Feel free to add more / adjust the names as appropriate. I am trying to find someone who can help manage the migration from Trac.
Are the github issues set up sufficiently for Trac to be disabled and github to take over?
You lost me here. You were going to set up a test site where we could see the Trac --> Github conversion could be tested, before actually pushing that conversion to the numpy Github repo. If you sent a message that that was ready, I must have missed it.
The current state of labels on https://github.com/numpy/numpy/issues is also far from complete (no prios, components).
I wasn't completely clear. What I meant to ask:
"Are the github issues (and labels) set up well enough for Trac to be disabled for accepting new bugs and to point users filing new bugs to github instead?"
(The answer to which is "no", based on your reply).
I don't think it's a problem that a few issues have already been filed on Github, but we'll have to properly label them by hand later.
Making Github the default or only option now would be a bit strange. It would be better to first do the conversion, or at least have it far enough along that we have agreed on workflow and labels to use.
My concern is that transitioning first would define the workflow/labels based on what's in Trac, rather than on what would work best with github. But maybe the best way to move things forward is to do the transition to a test project, and see what comes out. Ray Jones
On Sat, Jun 23, 2012 at 11:30 AM, Thouis (Ray) Jones <thouis@gmail.com>wrote:
On Sat, Jun 23, 2012 at 11:13 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones <thouis@gmail.com
wrote:
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant <travis@continuum.io
wrote:
I have turned on issue tracking and started a few labels. Feel
to add more / adjust the names as appropriate. I am trying to find someone who can help manage the migration from Trac.
Are the github issues set up sufficiently for Trac to be disabled and github to take over?
You lost me here. You were going to set up a test site where we could see the Trac --> Github conversion could be tested, before actually
free pushing
that conversion to the numpy Github repo. If you sent a message that that was ready, I must have missed it.
The current state of labels on https://github.com/numpy/numpy/issuesis also far from complete (no prios, components).
I wasn't completely clear. What I meant to ask:
"Are the github issues (and labels) set up well enough for Trac to be disabled for accepting new bugs and to point users filing new bugs to github instead?"
(The answer to which is "no", based on your reply).
I don't think it's a problem that a few issues have already been filed on Github, but we'll have to properly label them by hand later.
Making Github the default or only option now would be a bit strange. It would be better to first do the conversion, or at least have it far enough along that we have agreed on workflow and labels to use.
My concern is that transitioning first would define the workflow/labels based on what's in Trac, rather than on what would work best with github.
Trac is not unique, most bug trackers have similar concepts (milestones, components, prios, issue types).
But maybe the best way to move things forward is to do the transition to a test project, and see what comes out.
+1 Ralf
On Sun, Jun 24, 2012 at 12:31 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sat, Jun 23, 2012 at 11:30 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Sat, Jun 23, 2012 at 11:13 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant <travis@continuum.io> wrote: > I have turned on issue tracking and started a few labels. Feel > free > to > add > more / adjust the names as appropriate. I am trying to find > someone > who > can help manage the migration from Trac.
Are the github issues set up sufficiently for Trac to be disabled and github to take over?
You lost me here. You were going to set up a test site where we could see the Trac --> Github conversion could be tested, before actually pushing that conversion to the numpy Github repo. If you sent a message that that was ready, I must have missed it.
The current state of labels on https://github.com/numpy/numpy/issues is also far from complete (no prios, components).
I wasn't completely clear. What I meant to ask:
"Are the github issues (and labels) set up well enough for Trac to be disabled for accepting new bugs and to point users filing new bugs to github instead?"
(The answer to which is "no", based on your reply).
I don't think it's a problem that a few issues have already been filed on Github, but we'll have to properly label them by hand later.
Making Github the default or only option now would be a bit strange. It would be better to first do the conversion, or at least have it far enough along that we have agreed on workflow and labels to use.
My concern is that transitioning first would define the workflow/labels based on what's in Trac, rather than on what would work best with github.
Trac is not unique, most bug trackers have similar concepts (milestones, components, prios, issue types).
But maybe the best way to move things forward is to do the transition to a test project, and see what comes out.
Ok, so scipy.org was down again because of trac. Unfortunately, the machine on which scipy.org lives is the same as trac, and is a bit messy. I would really like to accelerate whatever needs to be done to get that done, both to get out of trac's misery, and to make scipy.org more responsive. I can't promise a lot of spare cycles, but I will make sure there are no roadblocks on Enthought side when we need to make the actual migration. Thouis, what needs to be done to make a testbed of the conversion ? David
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau <cournape@gmail.com> wrote:
Thouis, what needs to be done to make a testbed of the conversion ?
I just returned to this a couple of days ago [*], and last night successfully imported all the trac issues (from my somewhat out-of-date snapshot) to this repo: https://github.com/thouis/numpy-trac-migration Note that there are currently multiple copies of many issues. This is because github has no way to actually delete an issue, and I didn't bother marking issues that were from failed runs during debugging. If you see two copies of an issue with differences in their body/comments, the one with the higher github issue # is the one generated last night. The code that actually does the import is in that repository, as well. Thanks to the networkX group for alpha-testing the code. Ray [*] sorry for the delay... international move + starting a new job
On Thu, Sep 27, 2012 at 8:22 AM, Thouis (Ray) Jones <thouis@gmail.com>wrote:
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau <cournape@gmail.com> wrote:
Thouis, what needs to be done to make a testbed of the conversion ?
I just returned to this a couple of days ago [*], and last night successfully imported all the trac issues (from my somewhat out-of-date snapshot) to this repo: https://github.com/thouis/numpy-trac-migration
Note that there are currently multiple copies of many issues. This is because github has no way to actually delete an issue, and I didn't bother marking issues that were from failed runs during debugging. If you see two copies of an issue with differences in their body/comments, the one with the higher github issue # is the one generated last night.
The code that actually does the import is in that repository, as well. Thanks to the networkX group for alpha-testing the code.
Thouis, will you want commit privileges? Chuck
On Thu, Sep 27, 2012 at 11:46 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Sep 27, 2012 at 8:22 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau <cournape@gmail.com> wrote:
Thouis, what needs to be done to make a testbed of the conversion ?
I just returned to this a couple of days ago [*], and last night successfully imported all the trac issues (from my somewhat out-of-date snapshot) to this repo: https://github.com/thouis/numpy-trac-migration
Note that there are currently multiple copies of many issues. This is because github has no way to actually delete an issue, and I didn't bother marking issues that were from failed runs during debugging. If you see two copies of an issue with differences in their body/comments, the one with the higher github issue # is the one generated last night.
The code that actually does the import is in that repository, as well. Thanks to the networkX group for alpha-testing the code.
Thouis, will you want commit privileges?
Yes, though I created a bot account to keep from injecting myself into the history: https://github.com/numpy-gitbot Someone could also just run the import as the "numpy" github user. Ray
On Thu, Sep 27, 2012 at 9:58 AM, Thouis (Ray) Jones <thouis@gmail.com>wrote:
On Thu, Sep 27, 2012 at 11:46 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Thu, Sep 27, 2012 at 8:22 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau <cournape@gmail.com> wrote:
Thouis, what needs to be done to make a testbed of the conversion ?
I just returned to this a couple of days ago [*], and last night successfully imported all the trac issues (from my somewhat out-of-date snapshot) to this repo: https://github.com/thouis/numpy-trac-migration
Note that there are currently multiple copies of many issues. This is because github has no way to actually delete an issue, and I didn't bother marking issues that were from failed runs during debugging. If you see two copies of an issue with differences in their body/comments, the one with the higher github issue # is the one generated last night.
The code that actually does the import is in that repository, as well. Thanks to the networkX group for alpha-testing the code.
Thouis, will you want commit privileges?
Yes, though I created a bot account to keep from injecting myself into the history: https://github.com/numpy-gitbot
Someone could also just run the import as the "numpy" github user.
You're in. Chuck
On Thu, Sep 27, 2012 at 3:22 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau <cournape@gmail.com> wrote:
Thouis, what needs to be done to make a testbed of the conversion ?
I just returned to this a couple of days ago [*], and last night successfully imported all the trac issues (from my somewhat out-of-date snapshot) to this repo: https://github.com/thouis/numpy-trac-migration
Skimmed some of the bugs: The "(migrated from Trac #xxx)" in all the bug titles is kind of intrusive and distracting -- maybe reduce this to just "(was Trac #xxx)" or even "(Trac#xxx)" or so? https://github.com/thouis/numpy-trac-migration/issues/3783: "Reported 2011-03-04 by atmention:rgommers, assigned to unknown." <- This atmention thing looks like a bug. In the main body of the bug (and also in some comments), your code managed to convert one {{{source-code block}}} into a ```source-code block```, but failed on several others. "Comment in Trac by atmention:rgommers, 2012-05-19" <-- aside from the atmention: thing, wouldn't it be better to put the commenter first so it's more visible when skimming comments? Maybe something like "@rgommers wrote on 2012-05-19:"? "Marked as knownfail in 1.6.x branch in commit:6922cf8" <- fails to create a link to the commit. https://github.com/thouis/numpy-trac-migration/issues/3777: There are several mysterious empty comments here. (Apparently they came from milestone change messages.) Maybe this is already fixed, b/c I saw other milestone change messages, but fyi. https://github.com/thouis/numpy-trac-migration/issues/3774: Some originally-bold text has mysterious punctuation marks instead. ('''Problem''', '''Expectation of Behavior''', ...) https://github.com/thouis/numpy-trac-migration/issues/3760#issuecomment-8939...: This comment refers to an attachment by linking directly into the original trac instance. Are we going to keep trac alive indefinitely to serve these links, or is there some other plan...? For the boilerplate text at the beginning of every ticket ("Original ticket http://projects.scipy.org/numpy/ticket/1155\nReported 2009-06-30 by trac user gorm, assigned to atmention:rgommers."), it would be nice if it were somehow set off visually to make clearer where the actual start of the ticket text is. Maybe it could be italicized, or we could put a rule underneath it, or something? --- Anyway, these are mostly nitpicks (all except the attachment thing I guess, that seems like it could be a problem). Thanks so much for your work on this; it's really appreciated. -n
tl;dr I think I fixed everything mentioned below. On Thu, Sep 27, 2012 at 7:10 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Thu, Sep 27, 2012 at 3:22 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau <cournape@gmail.com> wrote:
Thouis, what needs to be done to make a testbed of the conversion ?
I just returned to this a couple of days ago [*], and last night successfully imported all the trac issues (from my somewhat out-of-date snapshot) to this repo: https://github.com/thouis/numpy-trac-migration
Skimmed some of the bugs:
The "(migrated from Trac #xxx)" in all the bug titles is kind of intrusive and distracting -- maybe reduce this to just "(was Trac #xxx)" or even "(Trac#xxx)" or so?
Changed to the last suggestion.
https://github.com/thouis/numpy-trac-migration/issues/3783:
"Reported 2011-03-04 by atmention:rgommers, assigned to unknown." <- This atmention thing looks like a bug.
This is to prevent @user notifications from occurring during testing. I'll switch it to an actual "@" when it's time to do the actual import.
In the main body of the bug (and also in some comments), your code managed to convert one {{{source-code block}}} into a ```source-code block```, but failed on several others.
It appears that github markup requires indented blocks to be separated by an empty line. Fixed. See: https://github.com/thouis/numpy-trac-migration/issues/3794
"Comment in Trac by atmention:rgommers, 2012-05-19" <-- aside from the atmention: thing, wouldn't it be better to put the commenter first so it's more visible when skimming comments? Maybe something like "@rgommers wrote on 2012-05-19:"?
Done.
"Marked as knownfail in 1.6.x branch in commit:6922cf8" <- fails to create a link to the commit.
Fixed.
https://github.com/thouis/numpy-trac-migration/issues/3777: There are several mysterious empty comments here. (Apparently they came from milestone change messages.) Maybe this is already fixed, b/c I saw other milestone change messages, but fyi.
I think this has been fixed in the latest code (but not all issues have used that for importing). See: https://github.com/thouis/numpy-trac-migration/issues/3786
https://github.com/thouis/numpy-trac-migration/issues/3774: Some originally-bold text has mysterious punctuation marks instead. ('''Problem''', '''Expectation of Behavior''', ...) Fixed. https://github.com/thouis/numpy-trac-migration/issues/3788
https://github.com/thouis/numpy-trac-migration/issues/3760#issuecomment-8939...: This comment refers to an attachment by linking directly into the original trac instance. Are we going to keep trac alive indefinitely to serve these links, or is there some other plan...?
The plan is to keep these around indefinitely (possibly as a snapshot). If they are moved in the future, automatic rewriting should be possible.
For the boilerplate text at the beginning of every ticket ("Original ticket http://projects.scipy.org/numpy/ticket/1155\nReported 2009-06-30 by trac user gorm, assigned to atmention:rgommers."), it would be nice if it were somehow set off visually to make clearer where the actual start of the ticket text is. Maybe it could be italicized, or we could put a rule underneath it, or something?
Like this? https://github.com/thouis/numpy-trac-migration/issues/3792 Ray
On Thu, Sep 27, 2012 at 10:09 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
tl;dr I think I fixed everything mentioned below.
By the way, my current method is to address bugs in the import by just reimporting tickets that demonstrate the bug, and not worrying about old versions of that ticket. If in browsing through you come upon an apparent bug, it's worth searching for the Trac # to make sure there isn't a more recent version with the bug fixed. I think things are close to ready. I still need to file a numpy warning/issue that mentions everyone that's going to be @mentioned in the full import, to make sure they're aware of what's coming and can filter appropriately, or request I remove them from the trac-to-github username map. Ray
On Fri, Sep 28, 2012 at 4:20 AM, Thouis (Ray) Jones <thouis@gmail.com>wrote:
On Thu, Sep 27, 2012 at 10:09 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
tl;dr I think I fixed everything mentioned below.
By the way, my current method is to address bugs in the import by just reimporting tickets that demonstrate the bug, and not worrying about old versions of that ticket. If in browsing through you come upon an apparent bug, it's worth searching for the Trac # to make sure there isn't a more recent version with the bug fixed.
I think things are close to ready. I still need to file a numpy warning/issue that mentions everyone that's going to be @mentioned in the full import, to make sure they're aware of what's coming and can filter appropriately, or request I remove them from the trac-to-github username map.
Looks great! After a quick browse, the only thing I noticed that still needs some thought is the color scheme for the labels. Ralf
I plan to import all the Trac issues to github by the end of this week. I want to get an up-to-date snapshot of the Trac DB, and run another test import with it (just to make sure there's nothing in recent bugs that isn't handled). Previous test imports here: https://github.com/thouis/numpy-trac-migration/issues Ray
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I plan to import all the Trac issues to github by the end of this week. I want to get an up-to-date snapshot of the Trac DB, and run another test import with it (just to make sure there's nothing in recent bugs that isn't handled).
Previous test imports here: https://github.com/thouis/numpy-trac-migration/issues
I successfully imported all the issues from a more recent snapshot to the test repository as @numpy-gitbot, rather than @thouis (to save myself from getting pulled into every bug's discussion). If no one sees any problems with the latest imports (basically, the last 2000 or so by github issue #) , I think it's ready for the real transfer to the numpy github repository. Ray
On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I plan to import all the Trac issues to github by the end of this week. I want to get an up-to-date snapshot of the Trac DB, and run another test import with it (just to make sure there's nothing in recent bugs that isn't handled).
Previous test imports here: https://github.com/thouis/numpy-trac-migration/issues
I successfully imported all the issues from a more recent snapshot to the test repository as @numpy-gitbot, rather than @thouis (to save myself from getting pulled into every bug's discussion).
If no one sees any problems with the latest imports (basically, the last 2000 or so by github issue #) , I think it's ready for the real transfer to the numpy github repository.
This is really fabulous; thanks for all the effort you've put in! But... I am quite concerned that we're still linking to attachments in the trac, e.g.: https://github.com/thouis/numpy-trac-migration/issues/6002#issuecomment-9492... This means that we can't ever take down the trac without breaking all our github issues; we're committing to keeping the trac running indefinitely. Doesn't that kind of defeat a lot of the point...? -n
On Tue, Oct 16, 2012 at 5:54 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I plan to import all the Trac issues to github by the end of this week. I want to get an up-to-date snapshot of the Trac DB, and run another test import with it (just to make sure there's nothing in recent bugs that isn't handled).
Previous test imports here: https://github.com/thouis/numpy-trac-migration/issues
I successfully imported all the issues from a more recent snapshot to the test repository as @numpy-gitbot, rather than @thouis (to save myself from getting pulled into every bug's discussion).
If no one sees any problems with the latest imports (basically, the last 2000 or so by github issue #) , I think it's ready for the real transfer to the numpy github repository.
This is really fabulous; thanks for all the effort you've put in!
But... I am quite concerned that we're still linking to attachments in the trac, e.g.: https://github.com/thouis/numpy-trac-migration/issues/6002#issuecomment-9492...
This means that we can't ever take down the trac without breaking all our github issues; we're committing to keeping the trac running indefinitely. Doesn't that kind of defeat a lot of the point...?
Not actually. I have a snapshot of the attachments, as well, and once there's a place for them live (another repository, possibly), we can use the github API to edit the issues in place to point to the new URLs. Ray
On Tue, Oct 16, 2012 at 11:54 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I plan to import all the Trac issues to github by the end of this week. I want to get an up-to-date snapshot of the Trac DB, and run another test import with it (just to make sure there's nothing in recent bugs that isn't handled).
Previous test imports here: https://github.com/thouis/numpy-trac-migration/issues
I successfully imported all the issues from a more recent snapshot to the test repository as @numpy-gitbot, rather than @thouis (to save myself from getting pulled into every bug's discussion).
If no one sees any problems with the latest imports (basically, the last 2000 or so by github issue #) , I think it's ready for the real transfer to the numpy github repository.
This is really fabulous; thanks for all the effort you've put in!
Looks great to me too, don't see anything missing. Thanks a lot Ray! Ralf
But... I am quite concerned that we're still linking to attachments in the trac, e.g.:
https://github.com/thouis/numpy-trac-migration/issues/6002#issuecomment-9492...
This means that we can't ever take down the trac without breaking all our github issues; we're committing to keeping the trac running indefinitely. Doesn't that kind of defeat a lot of the point...?
-n _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Oct 17, 2012 at 4:44 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Tue, Oct 16, 2012 at 11:54 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I plan to import all the Trac issues to github by the end of this week. I want to get an up-to-date snapshot of the Trac DB, and run another test import with it (just to make sure there's nothing in recent bugs that isn't handled).
Previous test imports here: https://github.com/thouis/numpy-trac-migration/issues
I successfully imported all the issues from a more recent snapshot to the test repository as @numpy-gitbot, rather than @thouis (to save myself from getting pulled into every bug's discussion).
If no one sees any problems with the latest imports (basically, the last 2000 or so by github issue #) , I think it's ready for the real transfer to the numpy github repository.
This is really fabulous; thanks for all the effort you've put in!
Looks great to me too, don't see anything missing. Thanks a lot Ray!
Ralf
But... I am quite concerned that we're still linking to attachments in the trac, e.g.:
https://github.com/thouis/numpy-trac-migration/issues/6002#issuecomment-9492...
This means that we can't ever take down the trac without breaking all our github issues; we're committing to keeping the trac running indefinitely. Doesn't that kind of defeat a lot of the point...?
-n _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
I plan to run the migration tomorrow (I promised the git users that will be @-mentioned a day's warning, which I forgot to send until now). Ray
I started the import with the oldest 75 and newest 125 Trac issues, and will wait a few hours to do the rest to allow feedback, just in case something is broken that I haven't noticed. I did make one change to better emulate Trac behavior. Some Trac usernames are also email addresses, which Trac anonymizes in its display. I decided it was safer to do the same. Ray Jones
Kudos! Ray. Very impressive and useful work. -Travis On Oct 19, 2012, at 10:20 AM, Thouis (Ray) Jones wrote:
I started the import with the oldest 75 and newest 125 Trac issues, and will wait a few hours to do the rest to allow feedback, just in case something is broken that I haven't noticed.
I did make one change to better emulate Trac behavior. Some Trac usernames are also email addresses, which Trac anonymizes in its display. I decided it was safer to do the same.
Ray Jones _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Fri, Oct 19, 2012 at 8:56 AM, Travis Oliphant <travis@continuum.io> wrote:
Kudos! Ray.
Very impressive and useful work.
Indeed, many thanks, Ray!! This has been a ton of work, and somewhat thankless b/c it's for a one-off thing. What I did for our lanunchpad bug migration was a far more hackish/dirty job precisely for that reason, so I applaud you for your patience to do this right. Cheers, f
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I started the import with the oldest 75 and newest 125 Trac issues, and will wait a few hours to do the rest to allow feedback, just in case something is broken that I haven't noticed.
I did make one change to better emulate Trac behavior. Some Trac usernames are also email addresses, which Trac anonymizes in its display. I decided it was safer to do the same.
The import is running again, though I've been having some failures in a few comments and general hangs (these might be network related). I'm keeping track of which issues might have had difficulties. @endolith noticed that I didn't correctly relink #XXX trac id numbers to github id numbers (both trac and github create links automatically), so that will have to be handled by a postprocessing script (which it probably would have, anyway, since the github # isn't known before import). Ray
On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I started the import with the oldest 75 and newest 125 Trac issues, and will wait a few hours to do the rest to allow feedback, just in case something is broken that I haven't noticed.
I did make one change to better emulate Trac behavior. Some Trac usernames are also email addresses, which Trac anonymizes in its display. I decided it was safer to do the same.
The import is running again, though I've been having some failures in a few comments and general hangs (these might be network related). I'm keeping track of which issues might have had difficulties.
@endolith noticed that I didn't correctly relink #XXX trac id numbers to github id numbers (both trac and github create links automatically), so that will have to be handled by a postprocessing script (which it probably would have, anyway, since the github # isn't known before import).
Import has finished. The following trac #s had issues in creating the comments (I think due to network problems): 182, 297, 619, 621, 902, 904, 909 913, 914, 915, 1044, 1526. I'll review them and see if I can pull in anything missing I'll also work on a script for updating the trac crossrefs to github crossrefs. In the "no good deed goes unpunished" category, I accidentally logged in as myself (rather than numpy-gitbot) and pushed about 500 issues, so now I receive updates whenever one of them gets changed. At least most of them were closed, already... Ray
Also, it looks like Trac issues 2228 and up weren't in the snapshot of the DB I had. Those should be imported after Trac is disabled for new bugs. Ray
On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I started the import with the oldest 75 and newest 125 Trac issues, and will wait a few hours to do the rest to allow feedback, just in case something is broken that I haven't noticed.
I did make one change to better emulate Trac behavior. Some Trac usernames are also email addresses, which Trac anonymizes in its display. I decided it was safer to do the same.
The import is running again, though I've been having some failures in a few comments and general hangs (these might be network related). I'm keeping track of which issues might have had difficulties.
@endolith noticed that I didn't correctly relink #XXX trac id numbers to github id numbers (both trac and github create links automatically), so that will have to be handled by a postprocessing script (which it probably would have, anyway, since the github # isn't known before import).
Import has finished.
The following trac #s had issues in creating the comments (I think due to network problems): 182, 297, 619, 621, 902, 904, 909 913, 914, 915, 1044, 1526. I'll review them and see if I can pull in anything missing
I'll also work on a script for updating the trac crossrefs to github crossrefs.
In the "no good deed goes unpunished" category, I accidentally logged in as myself (rather than numpy-gitbot) and pushed about 500 issues, so now I receive updates whenever one of them gets changed. At least most of them were closed, already...
I just updated the cross-issue-references to use github rather than Trac id numbers. Stupidly, I may have accidentally removed comments that were added in the last few days to issues moved from trac to github. Hopefully not, or at least not many. It's probably a good idea to turn off Trac, soon, to keep too many new bugs from needing to be ported, and old bugs being commented on. The latter is more of a pain to deal with. Ray
On Tue, Oct 23, 2012 at 5:05 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I started the import with the oldest 75 and newest 125 Trac issues, and will wait a few hours to do the rest to allow feedback, just in case something is broken that I haven't noticed.
I did make one change to better emulate Trac behavior. Some Trac usernames are also email addresses, which Trac anonymizes in its display. I decided it was safer to do the same.
The import is running again, though I've been having some failures in a few comments and general hangs (these might be network related). I'm keeping track of which issues might have had difficulties.
@endolith noticed that I didn't correctly relink #XXX trac id numbers to github id numbers (both trac and github create links automatically), so that will have to be handled by a postprocessing script (which it probably would have, anyway, since the github # isn't known before import).
Import has finished.
The following trac #s had issues in creating the comments (I think due to network problems): 182, 297, 619, 621, 902, 904, 909 913, 914, 915, 1044, 1526. I'll review them and see if I can pull in anything missing
I'll also work on a script for updating the trac crossrefs to github crossrefs.
In the "no good deed goes unpunished" category, I accidentally logged in as myself (rather than numpy-gitbot) and pushed about 500 issues, so now I receive updates whenever one of them gets changed. At least most of them were closed, already...
I just updated the cross-issue-references to use github rather than Trac id numbers. Stupidly, I may have accidentally removed comments that were added in the last few days to issues moved from trac to github. Hopefully not, or at least not many.
It's probably a good idea to turn off Trac, soon, to keep too many new bugs from needing to be ported, and old bugs being commented on. The latter is more of a pain to deal with.
I will look into making the NumPy trac read-only. It should not be too complicated to extend Pauli's code to redirect the tickets part to github issues. Have we decided what to do with the wiki content ? David
On Oct 23, 2012, at 9:58 AM, David Cournapeau wrote:
On Tue, Oct 23, 2012 at 5:05 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
I started the import with the oldest 75 and newest 125 Trac issues, and will wait a few hours to do the rest to allow feedback, just in case something is broken that I haven't noticed.
I did make one change to better emulate Trac behavior. Some Trac usernames are also email addresses, which Trac anonymizes in its display. I decided it was safer to do the same.
The import is running again, though I've been having some failures in a few comments and general hangs (these might be network related). I'm keeping track of which issues might have had difficulties.
@endolith noticed that I didn't correctly relink #XXX trac id numbers to github id numbers (both trac and github create links automatically), so that will have to be handled by a postprocessing script (which it probably would have, anyway, since the github # isn't known before import).
Import has finished.
The following trac #s had issues in creating the comments (I think due to network problems): 182, 297, 619, 621, 902, 904, 909 913, 914, 915, 1044, 1526. I'll review them and see if I can pull in anything missing
I'll also work on a script for updating the trac crossrefs to github crossrefs.
In the "no good deed goes unpunished" category, I accidentally logged in as myself (rather than numpy-gitbot) and pushed about 500 issues, so now I receive updates whenever one of them gets changed. At least most of them were closed, already...
I just updated the cross-issue-references to use github rather than Trac id numbers. Stupidly, I may have accidentally removed comments that were added in the last few days to issues moved from trac to github. Hopefully not, or at least not many.
It's probably a good idea to turn off Trac, soon, to keep too many new bugs from needing to be ported, and old bugs being commented on. The latter is more of a pain to deal with.
I will look into making the NumPy trac read-only. It should not be too complicated to extend Pauli's code to redirect the tickets part to github issues.
Have we decided what to do with the wiki content ?
I believe there is a wiki dump command in trac wiki. We should put that content linked off the numpy pages at github. Thanks for helping with this. -Travis
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Oct 23, 2012 at 5:13 PM, Travis Oliphant <travis@continuum.io>wrote:
On Oct 23, 2012, at 9:58 AM, David Cournapeau wrote:
On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones <
On Tue, Oct 23, 2012 at 5:05 AM, Thouis (Ray) Jones <thouis@gmail.com> wrote: thouis@gmail.com> wrote:
I started the import with the oldest 75 and newest 125 Trac issues, and will wait a few hours to do the rest to allow feedback, just in case something is broken that I haven't noticed.
I did make one change to better emulate Trac behavior. Some Trac usernames are also email addresses, which Trac anonymizes in its display. I decided it was safer to do the same.
The import is running again, though I've been having some failures in a few comments and general hangs (these might be network related). I'm keeping track of which issues might have had difficulties.
@endolith noticed that I didn't correctly relink #XXX trac id numbers to github id numbers (both trac and github create links automatically), so that will have to be handled by a postprocessing script (which it probably would have, anyway, since the github # isn't known before import).
Import has finished.
The following trac #s had issues in creating the comments (I think due to network problems): 182, 297, 619, 621, 902, 904, 909 913, 914, 915, 1044, 1526. I'll review them and see if I can pull in anything missing
I'll also work on a script for updating the trac crossrefs to github crossrefs.
In the "no good deed goes unpunished" category, I accidentally logged in as myself (rather than numpy-gitbot) and pushed about 500 issues, so now I receive updates whenever one of them gets changed. At least most of them were closed, already...
I just updated the cross-issue-references to use github rather than Trac id numbers. Stupidly, I may have accidentally removed comments that were added in the last few days to issues moved from trac to github. Hopefully not, or at least not many.
It's probably a good idea to turn off Trac, soon, to keep too many new bugs from needing to be ported, and old bugs being commented on. The latter is more of a pain to deal with.
I will look into making the NumPy trac read-only. It should not be too complicated to extend Pauli's code to redirect the tickets part to github issues.
Have we decided what to do with the wiki content ?
I believe there is a wiki dump command in trac wiki. We should put that content linked off the numpy pages at github.
Please don't do that. Most of the content is either links to what was already moved into the numpy git repo, or very outdated stuff. I see at least two better options: - just leave the wiki pages as is, make them read only and add a clear warning "outdated" at the top. - move the rest of the useful content into the git repo, remove the rest Ralf
Thanks for helping with this.
-Travis
David _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Oct 23, 2012 at 10:58 AM, David Cournapeau <cournape@gmail.com> wrote:
I will look into making the NumPy trac read-only. It should not be too complicated to extend Pauli's code to redirect the tickets part to github issues.
If you need the map of trac IDs to github IDs, I have code to grab that. Ray
On Tue, Oct 23, 2012 at 8:57 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Tue, Oct 23, 2012 at 10:58 AM, David Cournapeau <cournape@gmail.com> wrote:
I will look into making the NumPy trac read-only. It should not be too complicated to extend Pauli's code to redirect the tickets part to github issues.
If you need the map of trac IDs to github IDs, I have code to grab that.
Oh, I meant something much simpler: just redirect the view issues link into GH :) David
27.09.2012 15:46, David Cournapeau kirjoitti: [clip]
Ok, so scipy.org was down again because of trac. Unfortunately, the machine on which scipy.org lives is the same as trac, and is a bit messy.
Trac runs on new.scipy.org, which AFAIK *is* a different machine from scipy.org. Pauli
27.09.2012 21:45, Pauli Virtanen kirjoitti:
27.09.2012 15:46, David Cournapeau kirjoitti: [clip]
Ok, so scipy.org was down again because of trac. Unfortunately, the machine on which scipy.org lives is the same as trac, and is a bit messy.
Trac runs on new.scipy.org, which AFAIK *is* a different machine from scipy.org.
Well, turns out that I was mistaken here, and David was right. Carry on... -- Pauli Virtanen
participants (9)
-
Charles R Harris -
David Cournapeau -
Fernando Perez -
Nathaniel Smith -
Pauli Virtanen -
Ralf Gommers -
Ralf Gommers -
Thouis (Ray) Jones -
Travis Oliphant