Re: [Numpy-discussion] Issue tracking
On Tue, Oct 23, 2012 at 5:05 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Oct 23, 2012, at 9:58 AM, David Cournapeau wrote: On Tue, Oct 23, 2012 at 5:05 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Tue, Oct 23, 2012 at 5:13 PM, Travis Oliphant tra...@continuum.iowrote: On Oct 23, 2012, at 9:58 AM, David Cournapeau wrote: On Tue, Oct 23, 2012 at 5:05 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Tue, Oct 23, 2012 at 10:58 AM, David Cournapeau courn...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Tue, Oct 23, 2012 at 8:57 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Tue, Oct 23, 2012 at 10:58 AM, David Cournapeau courn...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Fri, Oct 19, 2012 at 9:34 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
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
Re: [Numpy-discussion] Issue tracking
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Fri, Oct 19, 2012 at 4:46 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Oct 19, 2012 at 11:20 AM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Fri, Oct 19, 2012 at 8:56 AM, Travis Oliphant tra...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Wed, Oct 17, 2012 at 4:44 PM, Ralf Gommers ralf.gomm...@gmail.com wrote: On Tue, Oct 16, 2012 at 11:54 PM, Nathaniel Smith n...@pobox.com wrote: On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones tho...@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-9492223 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Tue, Oct 16, 2012 at 11:54 PM, Nathaniel Smith n...@pobox.com wrote: On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones tho...@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-9492223 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones tho...@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-9492223 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
Re: [Numpy-discussion] Issue tracking
On Tue, Oct 16, 2012 at 5:54 PM, Nathaniel Smith n...@pobox.com wrote: On Tue, Oct 16, 2012 at 9:06 PM, Thouis (Ray) Jones tho...@gmail.com wrote: On Sun, Oct 7, 2012 at 10:15 AM, Thouis (Ray) Jones tho...@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-9492223 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Fri, Sep 28, 2012 at 1:48 AM, Ralf Gommers ralf.gomm...@gmail.com wrote: Looks great! After a quick browse, the only thing I noticed that still needs some thought is the color scheme for the labels. That's easy to adjust afterwards. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Sun, Jun 24, 2012 at 12:31 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sat, Jun 23, 2012 at 11:30 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Sat, Jun 23, 2012 at 11:13 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau courn...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Thu, Sep 27, 2012 at 8:22 AM, Thouis (Ray) Jones tho...@gmail.comwrote: On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau courn...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Thu, Sep 27, 2012 at 9:58 AM, Thouis (Ray) Jones tho...@gmail.comwrote: On Thu, Sep 27, 2012 at 11:46 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Thu, Sep 27, 2012 at 8:22 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau courn...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Thu, Sep 27, 2012 at 3:22 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau courn...@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-8939552:
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
tl;dr I think I fixed everything mentioned below.
On Thu, Sep 27, 2012 at 7:10 PM, Nathaniel Smith n...@pobox.com wrote:
On Thu, Sep 27, 2012 at 3:22 PM, Thouis (Ray) Jones tho...@gmail.com wrote:
On Thu, Sep 27, 2012 at 8:46 AM, David Cournapeau courn...@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-8939552:
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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Thu, Sep 27, 2012 at 10:09 PM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Fri, Sep 28, 2012 at 4:20 AM, Thouis (Ray) Jones tho...@gmail.comwrote: On Thu, Sep 27, 2012 at 10:09 PM, Thouis (Ray) Jones tho...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Sat, Jun 23, 2012 at 11:30 AM, Thouis (Ray) Jones tho...@gmail.comwrote: On Sat, Jun 23, 2012 at 11:13 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@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/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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones tho...@gmail.comwrote: On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@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. 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Sat, Jun 23, 2012 at 11:13 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sat, Jun 23, 2012 at 11:03 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Fri, Jun 22, 2012 at 7:29 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones tho...@gmail.com wrote: On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Fri, Jun 22, 2012 at 9:49 AM, Thouis (Ray) Jones tho...@gmail.comwrote: On Mon, Jun 4, 2012 at 7:43 PM, Travis Oliphant tra...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris charlesr.har...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
On Mon, Jun 4, 2012 at 9:34 AM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris charlesr.har...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue tracking
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.har...@gmail.com wrote: On Mon, Jun 4, 2012 at 9:34 AM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Sun, Jun 3, 2012 at 10:06 PM, Charles R Harris charlesr.har...@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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Issue tracking
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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
+1 on migrating issues to GitHub, I'm so glad this discussion is happening. On Sat, May 5, 2012 at 8:28 PM, Charles R Harris charlesr.har...@gmail.com wrote: Uh oh. We are short on developers as is... Which brings up a question, do people need a github account to open an issue? Creating an account on GH is currently required, but it's automated and self-evident how to do that. This little anecdote may say more about me than it does about the Trac instance, but I think it makes a point anyway: I came across a minor numpy or scipy issue last week while running the test suite, which was in a part of the project I don't use, and wanted to quickly report it, (or maybe just add some details to an existing ticket, I don't recall). I went to the GH page first, and saw that only Pull Requests were handled there, so I figured it must still be on the Trac. I went there to try to open a new ticket and then got something like this message: Notice: You are currently not logged in. You may want to do so now. Error: Forbidden TICKET_CREATE privileges are required to perform this operation TracGuide — The Trac User and Administration Guide I tried to login and got an .htaccess login box in the browser - I tried to remember a username password combination that Jarrod set up for me back in 2008? each time I failed, I was then greeted with: Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. Apache/2.2.3 (CentOS) Server at projects.scipy.org Port 80 Of course, taking a look now, I should have either been more diligent about finding the forgot your password? link [1] or just created a new username [2], but at the time it seemed like there was no concrete way to proceed forward. With that, the error didn't seem important enough and I decided to get back to the matter at hand - so I gave up. :\ So it really is nice to have everything in one place. When matplotlib had its tickets on SourceForge, I rarely ventured over there to check them, but now that they are on GitHub, everyone with the commit bit gets an email when a new issue is opened, and it makes it a lot easier to pitch in and participate. 1. http://projects.scipy.org/numpy/reset_password 2. http://projects.scipy.org/numpy/register best, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Wed, May 2, 2012 at 11:25 PM, Wes McKinney wesmck...@gmail.com wrote: On Wed, May 2, 2012 at 9:48 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... That's amazing - not only does it not give errors anymore, it's also an order of magnitude faster. So maybe we could just stick with trac. Performance was really the sticking point. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion FWIW I'm pretty strongly in favor of GHI for NumPy/SciPy (I am going to get involved in NumPy dev eventually, promise). While warty in some of the places already mentioned, I have found it to be very low-friction and low-annoyance in my own dev process (nearing 1000 issues closed in the last year in pandas). But there are fewer cooks in the kitchen with pandas so perhaps this experience wouldn't be identical with NumPy. The biggest benefit I've seen is community involvement that you really wouldn't see if I were using a Trac or something else hosted elsewhere. Users are on GitHub and it for some reason gives people a feeling of engagement in the open source process that I don't see anywhere else. Feels like it's time to make a decision on this. I see no blocking objections against Github, so perhaps we should give it a go. The attachment issue for data files can be solved by relocating those to a server we still administer. Trac is currently annoying me also, because I need to change the milestone of ~50 tickets and have no good way of doing it. So nothing's perfect. Github's hosting service, possibly more user involvement and centralizing all our tools there may be enough to outweigh the limitations of GHI. Proposal: move NumPy tickets to Github. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Sat, May 5, 2012 at 1:28 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Wed, May 2, 2012 at 11:25 PM, Wes McKinney wesmck...@gmail.com wrote: On Wed, May 2, 2012 at 9:48 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... That's amazing - not only does it not give errors anymore, it's also an order of magnitude faster. So maybe we could just stick with trac. Performance was really the sticking point. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion FWIW I'm pretty strongly in favor of GHI for NumPy/SciPy (I am going to get involved in NumPy dev eventually, promise). While warty in some of the places already mentioned, I have found it to be very low-friction and low-annoyance in my own dev process (nearing 1000 issues closed in the last year in pandas). But there are fewer cooks in the kitchen with pandas so perhaps this experience wouldn't be identical with NumPy. The biggest benefit I've seen is community involvement that you really wouldn't see if I were using a Trac or something else hosted elsewhere. Users are on GitHub and it for some reason gives people a feeling of engagement in the open source process that I don't see anywhere else. Feels like it's time to make a decision on this. I see no blocking objections against Github, so perhaps we should give it a go. The attachment issue for data files can be solved by relocating those to a server we still administer. Trac is currently annoying me also, because I need to change the milestone of ~50 tickets and have no good way of doing it. So nothing's perfect. Github's hosting service, possibly more user involvement and centralizing all our tools there may be enough to outweigh the limitations of GHI. Proposal: move NumPy tickets to Github. +1. The move needs some planning. 1. Document workflow. 2. Change link and put explanation on the numpy bug report page. 3. Notify current registered trac users. 4. Import current tickets. The last is going to take significant effort if we need to label the issues and go through the attachments. We also need a 'moved' resolution to help with that. Some work on a script automating the process would pay off there. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On May 5, 2012, at 2:28 PM, Ralf Gommers wrote: On Wed, May 2, 2012 at 11:25 PM, Wes McKinney wesmck...@gmail.com wrote: On Wed, May 2, 2012 at 9:48 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... That's amazing - not only does it not give errors anymore, it's also an order of magnitude faster. So maybe we could just stick with trac. Performance was really the sticking point. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion FWIW I'm pretty strongly in favor of GHI for NumPy/SciPy (I am going to get involved in NumPy dev eventually, promise). While warty in some of the places already mentioned, I have found it to be very low-friction and low-annoyance in my own dev process (nearing 1000 issues closed in the last year in pandas). But there are fewer cooks in the kitchen with pandas so perhaps this experience wouldn't be identical with NumPy. The biggest benefit I've seen is community involvement that you really wouldn't see if I were using a Trac or something else hosted elsewhere. Users are on GitHub and it for some reason gives people a feeling of engagement in the open source process that I don't see anywhere else. Feels like it's time to make a decision on this. I see no blocking objections against Github, so perhaps we should give it a go. The attachment issue for data files can be solved by relocating those to a server we still administer. Trac is currently annoying me also, because I need to change the milestone of ~50 tickets and have no good way of doing it. So nothing's perfect. Github's hosting service, possibly more user involvement and centralizing all our tools there may be enough to outweigh the limitations of GHI. Proposal: move NumPy tickets to Github. +1 The process does need planning. We don't need to rush, but it would be great to get it done by end of June.To Charles' list and Ralf's suggestions, I would add setting up a server that can relay pull requests to the mailing list. NumFocus can setup that server and provide login permissions to those needing to administer it. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Sat, May 5, 2012 at 10:19 PM, Travis Oliphant tra...@continuum.iowrote: On May 5, 2012, at 2:28 PM, Ralf Gommers wrote: On Wed, May 2, 2012 at 11:25 PM, Wes McKinney wesmck...@gmail.com wrote: On Wed, May 2, 2012 at 9:48 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... That's amazing - not only does it not give errors anymore, it's also an order of magnitude faster. So maybe we could just stick with trac. Performance was really the sticking point. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion FWIW I'm pretty strongly in favor of GHI for NumPy/SciPy (I am going to get involved in NumPy dev eventually, promise). While warty in some of the places already mentioned, I have found it to be very low-friction and low-annoyance in my own dev process (nearing 1000 issues closed in the last year in pandas). But there are fewer cooks in the kitchen with pandas so perhaps this experience wouldn't be identical with NumPy. The biggest benefit I've seen is community involvement that you really wouldn't see if I were using a Trac or something else hosted elsewhere. Users are on GitHub and it for some reason gives people a feeling of engagement in the open source process that I don't see anywhere else. Feels like it's time to make a decision on this. I see no blocking objections against Github, so perhaps we should give it a go. The attachment issue for data files can be solved by relocating those to a server we still administer. Trac is currently annoying me also, because I need to change the milestone of ~50 tickets and have no good way of doing it. So nothing's perfect. Github's hosting service, possibly more user involvement and centralizing all our tools there may be enough to outweigh the limitations of GHI. Proposal: move NumPy tickets to Github. +1 The process does need planning. We don't need to rush, but it would be great to get it done by end of June.To Charles' list and Ralf's suggestions, I would add setting up a server that can relay pull requests to the mailing list. Don't know if you saw this, but it looks like Pauli is pretty far along in fixing this problem: http://thread.gmane.org/gmane.comp.python.numeric.general/49551/focus=49744 Ralf NumFocus can setup that server and provide login permissions to those needing to administer it. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
05.05.2012 22:53, Ralf Gommers kirjoitti: [clip] would be great to get it done by end of June.To Charles' list and Ralf's suggestions, I would add setting up a server that can relay pull requests to the mailing list. Don't know if you saw this, but it looks like Pauli is pretty far along in fixing this problem: http://thread.gmane.org/gmane.comp.python.numeric.general/49551/focus=49744 The only thing missing is really only the server configuration --- new.scipy.org could in principle do that, but its mail system seems to be configured so that it cannot send mail to the MLs. So, someone with roots on the machine needs to step up. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Saturday, May 5, 2012, Pauli Virtanen wrote: 05.05.2012 22:53, Ralf Gommers kirjoitti: [clip] would be great to get it done by end of June.To Charles' list and Ralf's suggestions, I would add setting up a server that can relay pull requests to the mailing list. Don't know if you saw this, but it looks like Pauli is pretty far along in fixing this problem: http://thread.gmane.org/gmane.comp.python.numeric.general/49551/focus=49744 The only thing missing is really only the server configuration --- new.scipy.org could in principle do that, but its mail system seems to be configured so that it cannot send mail to the MLs. So, someone with roots on the machine needs to step up. Pauli Just a quick lesson from matplotlib's migration of sourceforge bugs to github issues. Darren Dale did an excellent job with only a few hitches. The key one is that *every* issue migrated spawns a new email. This got old very fast. Second, because Darren did the migration, he became author for every single issue. He then got every single status change of every issue that we triaged the following few weeks. We don't hear much from Darren these days... I suspect the men in the white coats took him away... Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Sat, May 5, 2012 at 8:50 PM, Benjamin Root ben.r...@ou.edu wrote: On Saturday, May 5, 2012, Pauli Virtanen wrote: 05.05.2012 22:53, Ralf Gommers kirjoitti: [clip] would be great to get it done by end of June.To Charles' list and Ralf's suggestions, I would add setting up a server that can relay pull requests to the mailing list. Don't know if you saw this, but it looks like Pauli is pretty far along in fixing this problem: http://thread.gmane.org/gmane.comp.python.numeric.general/49551/focus=49744 The only thing missing is really only the server configuration --- new.scipy.org could in principle do that, but its mail system seems to be configured so that it cannot send mail to the MLs. So, someone with roots on the machine needs to step up. Pauli Just a quick lesson from matplotlib's migration of sourceforge bugs to github issues. Darren Dale did an excellent job with only a few hitches. The key one is that *every* issue migrated spawns a new email. This got old very fast. Second, because Darren did the migration, he became author for every single issue. He then got every single status change of every issue that we triaged the following few weeks. We don't hear much from Darren these days... I suspect the men in the white coats took him away... Uh oh. We are short on developers as is... Which brings up a question, do people need a github account to open an issue? Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Saturday, May 5, 2012, Charles R Harris wrote:
On Sat, May 5, 2012 at 8:50 PM, Benjamin Root
ben.r...@ou.edujavascript:_e({}, 'cvml', 'ben.r...@ou.edu');
wrote:
On Saturday, May 5, 2012, Pauli Virtanen wrote:
05.05.2012 22:53, Ralf Gommers kirjoitti:
[clip]
would be great to get it done by end of June.To Charles' list
and Ralf's suggestions, I would add setting up a server that can
relay pull requests to the mailing list.
Don't know if you saw this, but it looks like Pauli is pretty far along
in fixing this problem:
http://thread.gmane.org/gmane.comp.python.numeric.general/49551/focus=49744
The only thing missing is really only the server configuration ---
new.scipy.org could in principle do that, but its mail system seems to
be configured so that it cannot send mail to the MLs. So, someone with
roots on the machine needs to step up.
Pauli
Just a quick lesson from matplotlib's migration of sourceforge bugs to
github issues. Darren Dale did an excellent job with only a few hitches.
The key one is that *every* issue migrated spawns a new email. This got old
very fast. Second, because Darren did the migration, he became author for
every single issue. He then got every single status change of every issue
that we triaged the following few weeks.
We don't hear much from Darren these days... I suspect the men in the
white coats took him away...
Uh oh. We are short on developers as is... Which brings up a question, do
people need a github account to open an issue?
Chuck
Last time I checked, yes. But this hasn't seemed to slow things down for us.
Ben Root
P.S. - there are probably ways around the issues I described. I just
mentioning them so that whoever prepares the migration could look out for
those problems.
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Wed, May 2, 2012 at 9:48 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers ralf.gomm...@googlemail.com wrote: On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... That's amazing - not only does it not give errors anymore, it's also an order of magnitude faster. So maybe we could just stick with trac. Performance was really the sticking point. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion FWIW I'm pretty strongly in favor of GHI for NumPy/SciPy (I am going to get involved in NumPy dev eventually, promise). While warty in some of the places already mentioned, I have found it to be very low-friction and low-annoyance in my own dev process (nearing 1000 issues closed in the last year in pandas). But there are fewer cooks in the kitchen with pandas so perhaps this experience wouldn't be identical with NumPy. The biggest benefit I've seen is community involvement that you really wouldn't see if I were using a Trac or something else hosted elsewhere. Users are on GitHub and it for some reason gives people a feeling of engagement in the open source process that I don't see anywhere else. - Wes ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Mon, Apr 30, 2012 at 10:14 PM, Travis Oliphant tra...@continuum.iowrote: The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. There is a group where I work that purchased the enterprise version of github. But they still use trac. I think Ralf's opinion should count for a fair amount here, since the tracker is important for releases and backports. Having a good connection between commits and tickets is also very helpful, although sticking with github might be better there. The issue tracker isn't really intended as social media and I find the notifications from trac sufficient. Chuck I think Ralf and your opinion on this is *huge*. It seems that Issue tracking is at the heart of social media activity, though, because you need people to submit issues and you need people to respond to those issues in a timely way.And it is ideal if the dialogue that might ensue pursuant to that activity is discoverable via search and linking. But the issue tracking problem really is dividable into separate work flows: 1) The submission of the issue (here things like ease-of-entry and attaching files is critical) Yes, trac does allow attachments, but numpy trac locks up pretty often and I don't see why I should be locked out from submitting a comment just because someone else has made a comment while I've been typing. That said, trac does seem more responsive lately (thanks Pauli). I also don't find the trac interface attractive to look at, but it works. I could live without attachments, but they can be handy for scripts that demonstrate bugs and so on. As for fixes, I think we want to encourage pull requests rather than attached patches, but it might take a while before everyone is comfortable with that procedure. 2) The dialogue around the issue (developer comments on it and any discussion that ensues) I find the trac email notifications pretty good in that regard, although it would be nice to have everything in one place. The main issue I have, actually, is that github won't send me everything. I want to see every posted comment and every commit show up in the mail, including my own comments. The RSS feeds seem better for those notifications, but I have two feeds from github and they don't show the same things. Maybe we need to put together a tracking workflow document to supplement the git workflow document. I'd also like to see bug fix commits go in and automatically notify the tracker with an @#666 or some such. I don't know if that sort of thing is possible with the github tracker or the github hooks. 3) Developer management of issues This is where Ralf comes in as I don't regard myself as that familiar with trac. The problem in choosing a new system is that one needs to actually use it for some serious work to properly evaluate it. But we don't have the time to do that, so we ask. And then everyone has their own favorite, perhaps because it is the only one they have used. What impressed me was that Ralf seems to have actually used several different systems. Now, it is also true that these three things don't have to all intersect. It is very possible to have different systems manage different parts. What I find less than optimal these days is having github as the web-site for pull requests and discussions around them and a poorly-performing trac for issue tracking and milestone management and a few wiki pages. Can we at least agree to have all the wiki pages and web-site managed by github? For issue tracking, I'm very anxious for your and Ralf's opinion because of the effort you have spent using Trac over the years. It makes sense to move the wiki and web site. I hardly ever look at the developer Wiki anyway and might be more tempted to do so if it were up on github. It would also be good if those things could be managed in one place. As is, the permissions for managing things are split up and it isn't always clear who has the magic key. Another developer I asked at LLNL, just said why don't you use bugzilla? The simplest solution would be to use github, the question is whether the convenience and possibility of future improvements outweigh the better functionality of a dedicated system. In making that decision I think Ralf's opinion should carry the most weight since my experience in using trac for releases and such is much more limited than his. It might also be good to check on the ability of the different systems to export the data in some sensible format in case we change our minds. I suppose worker time and money are also part of the equation. If it looks like the github solution is cheaper and easier to manage, that in itself could be a
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 12:16 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Mon, Apr 30, 2012 at 10:14 PM, Travis Oliphant tra...@continuum.iowrote: The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. There is a group where I work that purchased the enterprise version of github. But they still use trac. I think Ralf's opinion should count for a fair amount here, since the tracker is important for releases and backports. Having a good connection between commits and tickets is also very helpful, although sticking with github might be better there. The issue tracker isn't really intended as social media and I find the notifications from trac sufficient. Chuck I think Ralf and your opinion on this is *huge*. It seems that Issue tracking is at the heart of social media activity, though, because you need people to submit issues and you need people to respond to those issues in a timely way.And it is ideal if the dialogue that might ensue pursuant to that activity is discoverable via search and linking. But the issue tracking problem really is dividable into separate work flows: 1) The submission of the issue (here things like ease-of-entry and attaching files is critical) Yes, trac does allow attachments, but numpy trac locks up pretty often and I don't see why I should be locked out from submitting a comment just because someone else has made a comment while I've been typing. That said, trac does seem more responsive lately (thanks Pauli). I also don't find the trac interface attractive to look at, but it works. I could live without attachments, but they can be handy for scripts that demonstrate bugs and so on. As for fixes, I think we want to encourage pull requests rather than attached patches, but it might take a while before everyone is comfortable with that procedure. 2) The dialogue around the issue (developer comments on it and any discussion that ensues) I find the trac email notifications pretty good in that regard, although it would be nice to have everything in one place. The main issue I have, actually, is that github won't send me everything. I want to see every posted comment and every commit show up in the mail, including my own comments. The RSS feeds seem better for those notifications, but I have two feeds from github and they don't show the same things. Maybe we need to put together a tracking workflow document to supplement the git workflow document. I'd also like to see bug fix commits go in and automatically notify the tracker with an @#666 or some such. I don't know if that sort of thing is possible with the github tracker or the github hooks. 3) Developer management of issues This is where Ralf comes in as I don't regard myself as that familiar with trac. The problem in choosing a new system is that one needs to actually use it for some serious work to properly evaluate it. But we don't have the time to do that, so we ask. And then everyone has their own favorite, perhaps because it is the only one they have used. What impressed me was that Ralf seems to have actually used several different systems. Now, it is also true that these three things don't have to all intersect. It is very possible to have different systems manage different parts. What I find less than optimal these days is having github as the web-site for pull requests and discussions around them and a poorly-performing trac for issue tracking and milestone management and a few wiki pages. Can we at least agree to have all the wiki pages and web-site managed by github? For issue tracking, I'm very anxious for your and Ralf's opinion because of the effort you have spent using Trac over the years. It makes sense to move the wiki and web site. I hardly ever look at the developer Wiki anyway and might be more tempted to do so if it were up on github. It would also be good if those things could be managed in one place. As is, the permissions for managing things are split up and it isn't always clear who has the magic key. Another developer I asked at LLNL, just said why don't you use bugzilla? The simplest solution would be to use github, the question is whether the convenience and possibility of future improvements outweigh the better functionality of a dedicated system. In making that decision I think Ralf's opinion should carry the most weight since my experience in using trac for releases and such is much more limited than his. It might also be good to check on the ability of the different systems to export the data in some sensible format in case we change our minds. I suppose worker time and
Re: [Numpy-discussion] Issue Tracking
On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can run any sort of query we want. With API data access, you can build your own queries, so maybe this isn't insurmountable. yes, you can build your own queries.This seems like an area where github
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.iowrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can run any sort of query we want. With API data access, you can build your own queries, so maybe this isn't insurmountable. yes, you can build your own queries.This
Re: [Numpy-discussion] Issue Tracking
01.05.2012 08:52, Travis Oliphant kirjoitti: [clip] 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. I'm not so sure this works for binary data. At least for Scipy, one sometimes needs to submit also data files. The needs here are probably somewhat different from IPython which can probably live with small text snippets, for which gists do work. The problem with using an external services I see is guaranteeing that the file still is there when you go looking for it (three years after the fact --- shouldn't happen in principle, but it does :). Dropbox I think is not good for this --- people will delete their stuff. I'm not sure about other attachment services. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 9:12 AM, Charles R Harris charlesr.har...@gmail.comwrote: On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.iowrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can run any sort of query we want. With API data access, you can build your own queries,
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 1:34 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Tue, May 1, 2012 at 9:12 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.iowrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can
Re: [Numpy-discussion] Issue Tracking
Hi folks, sorry for not jumping in before, swamped with deadlines... On Mon, Apr 30, 2012 at 8:14 PM, Jason Grout jason-s...@creativetrax.com wrote: I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project I think your summary is all very valid, and mostly we've just learned to live with some of its limitations and hacked around some of them. Now, one thing that the hyper-simplistic github tracker has made me think is about the value of over-sophisticated tools, which sometimes can become an end in and of themselves... Because the tracker is so absurdly simple, you just can't spend much time playing with it and may spend more time coding on the project itself. But having said that, I still think GHI (short for github issues) has *real* issues that are true limitations, and I keep hoping they'll improve (though it's starting to look more like unreasonable hope, as time goes by). 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I don't think it takes too much time in practice, but it's indeed a poor man's substitute for the google system. And for certain things, like priority, you *really* want a proper way of saying 'show me all issues of priority X or higher', which you can't do with labels. 2. The disjointed relationship between pull requests and issues. They This is the one that pisses me off the most. It's a real, constant drag to not be able to label issues and see those labels. I can't fathom why on Earth GH hasn't added this, and what bizarre thought process could possibly have led to PRs being implemented alongside issues and yet, being hobbled by deliberately *hiding* their labels. It feels almost as a misfeature written out of spite against the users. I fume every time I try to prioritize work on open PRs and have to do it via post-it notes on the wall because GH decided to *hide* the labels for PRs from me. Argh... 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. This one doesn't actually bother me in practice at all. Gist works perfectly for text snippets, and since they're version-controlled, it's even better than static attachments. And for images, a simple imgur upload (many screenshot programs even upload for you) along with  provides even better results: the images are inlined in the discussion. See for example: https://github.com/ipython/ipython/issues/1443 So here, I actually *prefer* gist+image urls to an attachment system. Arguably the externally hosted images could be lost if that server goes down, so it would perhaps be better to have them hosted at GH itself. They might consider that (or simply allowing gists to take binary uploads). 4. No custom queries. We love these in the Sage trac instance; since we have full access to the database, we can run any sort of query we want. With API data access, you can build your own queries, so maybe this isn't insurmountable. Yes, this is doable with a little elbow grease. 5. Stylistically, the webpage is not very dense on information. I get frustrated when trying to see the issues because they only come 25 at a time, and never grouped into any sort of groupings, and there are only 3 options for sorting issues. Compare the very nice, dense layout of Google Code issues or bitbucket. Google Code issues also lets you cross-tabulate the issues so you can quickly triage them. Compare also the pretty comprehensive options for sorting and grouping things in trac. Agreed. Not a big deal breaker for us, but perhaps we're just living in blissful ignorance of what we're missing :) 6. Side-by-side diffs are nice to have, and I believe bitbucket and google code both have them. Of course, this isn't a deal-breaker because you can always pull the branch down, but it would be nice to have, and there's not really a way we can put it into the github tracker ourselves. I guess they could add a markdown extension that displays a .diff url as a real diff... That said, it is nice to have code and dev conversations happening in one place. There are great things about github issues, of course. But I'm not so sure, for me, that they outweigh some of the administrative issues listed above. This is the real deal. In the end, we've learned to live with some of the GHI limitations and grumble under our breath about others, but there's genuine
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 2:17 PM, Charles R Harris charlesr.har...@gmail.comwrote: On Tue, May 1, 2012 at 1:34 PM, Ralf Gommers ralf.gomm...@googlemail.comwrote: On Tue, May 1, 2012 at 9:12 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.iowrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So pull requests *are* issues.This sounds like it might actually be a feature and also means that we *are* using the Github issue tracker (just only those issues that have a pull-request attached). Losing labels seems like a real problem (are they really lost or do they just not appear in the pull-request view?) 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. Using gists and references to gists can overcome this. Also using an attachment service like http://uploading.com/ or dropbox makes this problem less of an issue really. 4. No custom queries.
Re: [Numpy-discussion] Issue Tracking
On 5/1/12 3:19 PM, Fernando Perez wrote: But if you do decide to go with GHI, it should be based on what the system is like*today*, not on the hope that it will get better. About a month ago they broke label filtering by turning multi-label filters into an OR operation, which effectively rendered the labels completely useless. Despite reporting it multiple times via their support tracker AND speaking in person at someone from GH, it still took well over a month or two to fix. For something so simple and so essential, I consider that to be atrociously bad response. So don't go for GHI on the hope it will get a lot better soon, b/c their recent record doesn't support a hopeful viewpoint. This example indicates that basing your decision on what it is like *today* may not be valid either. You'd hope that they won't do something really silly, but you can't change it if they do, and you can't just keep running the old version of issues to avoid problems since you don't have control over that either. Anyway, like everyone else has said, Ralf, Pauli, et. al. are really the ones to vote in this. Given Fernando's responses, I realize why GHI still works for us---our small project has me and 2-4 students, and we all pretty much meet each week to triage issues together, and there are only about 40 open issues. It's a simple enough project that we need *something*, but we don't need to spend our time setting up complicated infrastructure. I do wish we could use Google Code issues with Github pull requests, though :). Thanks, Jason ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 1:36 PM, Jason Grout jason-s...@creativetrax.com wrote:
This example indicates that basing your decision on what it is like
*today* may not be valid either. You'd hope that they won't do
Very true ;)
Anyway, like everyone else has said, Ralf, Pauli, et. al. are really the
ones to vote in this. Given Fernando's responses, I realize why GHI
still works for us---our small project has me and 2-4 students, and we
all pretty much meet each week to triage issues together, and there are
only about 40 open issues. It's a simple enough project that we need
I just reread my reply with a full stomach, and I wanted to add
something, because I think it may appear a bit too negative. *In
practice*, the system does work very fluidly, and other than the
no-labels-on-PRs, it just gets out of your way. Being able to simply
type #NN in any comment or git commit ('closes #NN') and get
everything auto-linked, closed if needed, etc., has major value in
practice, and shouldn't be underestimated.
Using two separate tools adds real friction to the everyday workflow,
and if GH has taught me one thing, it's that the very fluid workflow
they enable leads to massive productivity improvements. For IPython,
the change from Launchpad/bzr to GH/git has been truly night and day
in terms of productivity. We process a volume of code today that
would be unthinkable before, and I think a big part of that is that
the tools simply get out of our way and let us just work.
So, as much as I do complain about real problems with GHI, I also
think it's important to evaluate carefully the cost of a dual-system
solution. Sometimes the lesser tool you know how to use is better
than the fancier one that creates friction. Put another way: no
matter how fancy your new $400 racket is, you'll never beat Pete
Sampras on a tennis court even if he's using a wood board to play :)
Cheers,
f
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
Thanks Ralf, I agree that Pauli and David have a lot of say in what we do. Thanks for reminding.We will wait to hear from them. If together you three feel like we should set up a separate Redmine instance than we can do that and just pay special attention with the Github integration and links in the right places to make sure the conversations stay connected. I just wanted to point out some of the benefits of Github that I've noticed. I can see pros and cons for both. Thanks for reminding me of the issue that users can't assign lables --- that must be done by a maintainer. That might be a benefit though, providing some control over how labels get assigned. Thanks, -Travis On May 1, 2012, at 2:34 PM, Ralf Gommers wrote: On Tue, May 1, 2012 at 9:12 AM, Charles R Harris charlesr.har...@gmail.com wrote: On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant tra...@continuum.io wrote: On Apr 30, 2012, at 10:14 PM, Jason Grout wrote: On 4/30/12 6:31 PM, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? I've been pretty impressed with the lemonade that the IPython folks have made out of what I see as pretty limiting shortcomings of the github issue tracker. I've been trying to use it for a much smaller project (https://github.com/sagemath/sagecell/), and it is a lot harder, in my (somewhat limited) experience, than using trac or the google issue tracker. None of these issues seems like it would be too hard to solve, but since we don't even have the source to the tracker, we're somewhat at github's mercy for any improvements. Github does have a very nice API for interacting with the data, which somewhat makes up for some of the severe shortcomings of the web interface. In no particular order, here are a few that come to mind immediately: 1. No key:value pairs for labels (Fernando brought this up a long time ago, I think). This is brilliant in Google code's tracker, and allows for custom fields that help in tracking workflow (like status, priority, etc.). Sure, you can do what the IPython folks are doing and just create labels for every possible status, but that's unwieldy and takes a lot of discipline to maintain. Which means it takes a lot of developer time or it becomes inconsistent and not very useful. I'm not sure how much of an issue this is. A lot of tools use single tags for categorization and it works pretty well. A simple key:value label communicates about the same information together with good query tools. 2. The disjointed relationship between pull requests and issues. They share numberings, for example, and both support discussions, etc. If you use the API, you can submit code to an issue, but then the issue becomes a pull request, which means that all labels on the issue disappear from the web interface (but you can still manage to set labels using the list view of the issue tracker, if I recall correctly). If you don't attach code to issues, it means that every issue is duplicated in a pull request, which splits the conversation up between an issue ticket and a pull request ticket. Hmm.. So
Re: [Numpy-discussion] Issue Tracking
01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] The main problem with Github (besides the issues/PRs thing and no attachments, which I can live with) is that to make it work we'll have to religiously label everything. And because users aren't allowed to attach labels, it will require a larger time investment from maintainers. Are we okay with that? If everyone else is and we can distribute this task, it's fine with me. I think this is probably not a very big deal, as long as there is a way of seeing the inbox of unlabeled bugs, and as long as the tracker sends mail about new bugs. The rate at which tickets are reported to us is at the moment not too that big. Triaging them will probably boil down to a five minutes of brainless work every second week, or so. David has been investigating bug trackers long before me, and Pauli has done most of the work administering Trac as far as I know, so I'd like to at least hear their preferences too before we make a decision. Then I hope we can move this along quickly, because any choice will be a huge improvement over the current situation. One big plus with Github compared to Redmine et al. is that someone else (TM) hosts it. One thing less to think about. Apart from the attachments issue, I don't have very big quibbles with the GH issue tracker. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 7:48 PM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... much better now If I were still going through tickets in scipy, I would prefer this view http://projects.scipy.org/scipy/query?status=applystatus=needs_decisionstatus=needs_infostatus=needs_reviewstatus=needs_workstatus=newstatus=reopenedcomponent=scipy.statsorder=status to something like this https://github.com/ipython/ipython/issues?direction=desclabels=windowspage=1sort=createdstate=open I never figured out how to effectively search in github, while with trac, I could always immediately reply to a question with the relevant link, or check the history instead of relying on memory. Josef Pauli ___ 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
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 6:18 PM, josef.p...@gmail.com wrote: On Tue, May 1, 2012 at 7:48 PM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... much better now If I were still going through tickets in scipy, I would prefer this view http://projects.scipy.org/scipy/query?status=applystatus=needs_decisionstatus=needs_infostatus=needs_reviewstatus=needs_workstatus=newstatus=reopenedcomponent=scipy.statsorder=status to something like this https://github.com/ipython/ipython/issues?direction=desclabels=windowspage=1sort=createdstate=open I never figured out how to effectively search in github, while with trac, I could always immediately reply to a question with the relevant link, or check the history instead of relying on memory. I would agree that a good search facility is essential, and not keyword/tag based. I've found some trac tickets with google on occasion, although not by initial intent. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 5:24 PM, Charles R Harris charlesr.har...@gmail.com wrote: I would agree that a good search facility is essential, and not keyword/tag based. Github issues does have full-text search, and up until now I haven't really had too many problems with it. No sophisticated filtering or anything, but basic search with the option to see open/closed/all issues seems to work OK. Josef I'm curious, which problems have you had with it? Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 8:29 PM, Fernando Perez fperez@gmail.com wrote: On Tue, May 1, 2012 at 5:24 PM, Charles R Harris charlesr.har...@gmail.com wrote: I would agree that a good search facility is essential, and not keyword/tag based. Github issues does have full-text search, and up until now I haven't really had too many problems with it. No sophisticated filtering or anything, but basic search with the option to see open/closed/all issues seems to work OK. Josef I'm curious, which problems have you had with it? maybe searching issues and pull requests is ok. The problem is that in statsmodels we did a lot of commits without pull requests, and I'm not very good searching in git either. (I don't remember which change I looked for but I got lost for half an hour searching for a change with git and github until I had to ask Skipper, who found it immediately.) What I was used to is integrated search without extra work, like this http://projects.scipy.org/scipy/search?q=mannwhitney and I had pretty much all the discussion to the history of a function. scipy.stats is easy too search because the function names are good search terms. scipy pull request don't have a search facility, as far as I was able to figure out, because the issues are not enabled, so I cannot check how good it would be. Josef Cheers, f ___ 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
Re: [Numpy-discussion] Issue Tracking
On Tue, May 1, 2012 at 6:04 PM, josef.p...@gmail.com wrote: maybe searching issues and pull requests is ok. The problem is that in statsmodels we did a lot of commits without pull requests, and I'm not very good searching in git either. (I don't remember which change I looked for but I got lost for half an hour searching for a change with git and github until I had to ask Skipper, who found it immediately.) What I was used to is integrated search without extra work, like this http://projects.scipy.org/scipy/search?q=mannwhitney and I had pretty much all the discussion to the history of a function. Ah, I see: the point was really the ability to search into the commit history directly through the web UI. Indeed, I'd never thought of that b/c I simply use the git machinery at the command-line for everything. But I can see how that Trac search box, with the ability to selectively tick on/off searching into commits, bugs, etc, could be very useful. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On 5/1/12 7:24 PM, Charles R Harris wrote: I would agree that a good search facility is essential, and not keyword/tag based. I've found some trac tickets with google on occasion, although not by initial intent. I use google to search the sage trac these days, using a shortcut to limit search results to the Sage trac site. To do this in Chrome, go to Preferences, then Basics, then Manage Search Engines. Down at the bottom, I fill in the three fields for a new search engine: Name: trac Keyword: t URL: http://www.google.com/#q=site:trac.sagemath.org+%s Then whenever I want to search trac, I just type t (t space) in the URL bar of Chrome, then type whatever I'm searching for. Google almost always pulls up the right ticket in the top few hits. And it's way faster than the trac search. Thanks, Jason ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen p...@iki.fi wrote: 01.05.2012 21:34, Ralf Gommers kirjoitti: [clip] At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) Now that it comes too late: with some luck, I've possibly hit on what was ailing the Tracs (max_diff_bytes configured too large). Let's see if things work better from now on... That's amazing - not only does it not give errors anymore, it's also an order of magnitude faster. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Monday, April 30, 2012, Travis Oliphant wrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. Comments, concerns? -Travis Would it be possible to use the combined clout of the scipy packages as a way to put some weight behind feature requests to github? Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Mon, Apr 30, 2012 at 5:31 PM, Travis Oliphant tra...@continuum.iowrote: Hey all, We have been doing some investigation of various approaches to issue tracking. The last time the conversation left this list was with Ralf's current list of preferences as: 1) Redmine 2) Trac 3) Github Since that time, Maggie who has been doing a lot of work settting up various issue tracking tools over the past couple of months, has set up a redmine instance and played with it. This is a possibility as a future issue tracker. However, today I took a hard look at what the IPython folks are doing with their issue tracker and was very impressed by the level of community integration that having issues tracked by Github provides.Right now, we have a major community problem in that there are 3 conversations taking place (well at least 2 1/2). One on Github, one on this list, and one on the Trac and it's accompanying wiki. I would like to propose just using Github's issue tracker.This just seems like the best move overall for us at this point.I like how the Pull Request mechanism integrates with the issue tracking.We could setup a Redmine instance but this would just re-create the same separation of communities that currently exists with the pull-requests, the mailing list, and the Trac pages. Redmine is nicer than Trac, but it's still a separate space. We need to make Github the NumPy developer hub and not have it spread throughout several sites. The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. There is a group where I work that purchased the enterprise version of github. But they still use trac. I think Ralf's opinion should count for a fair amount here, since the tracker is important for releases and backports. Having a good connection between commits and tickets is also very helpful, although sticking with github might be better there. The issue tracker isn't really intended as social media and I find the notifications from trac sufficient. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
The same is true of SciPy.I think if SciPy also migrates to use Github issues, then together with IPython we can really be a voice that helps Github. I will propose to NumFOCUS that the Foundation sponsor migration of the Trac to Github for NumPy and SciPy.If anyone would like to be involved in this migration project, please let me know. There is a group where I work that purchased the enterprise version of github. But they still use trac. I think Ralf's opinion should count for a fair amount here, since the tracker is important for releases and backports. Having a good connection between commits and tickets is also very helpful, although sticking with github might be better there. The issue tracker isn't really intended as social media and I find the notifications from trac sufficient. Chuck I think Ralf and your opinion on this is *huge*. It seems that Issue tracking is at the heart of social media activity, though, because you need people to submit issues and you need people to respond to those issues in a timely way.And it is ideal if the dialogue that might ensue pursuant to that activity is discoverable via search and linking. But the issue tracking problem really is dividable into separate work flows: 1) The submission of the issue (here things like ease-of-entry and attaching files is critical) 2) The dialogue around the issue (developer comments on it and any discussion that ensues) 3) Developer management of issues Now, it is also true that these three things don't have to all intersect. It is very possible to have different systems manage different parts.What I find less than optimal these days is having github as the web-site for pull requests and discussions around them and a poorly-performing trac for issue tracking and milestone management and a few wiki pages. Can we at least agree to have all the wiki pages and web-site managed by github? For issue tracking, I'm very anxious for your and Ralf's opinion because of the effort you have spent using Trac over the years. Another developer I asked at LLNL, just said why don't you use bugzilla? -Travis ___ 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
Re: [Numpy-discussion] Issue Tracking
Jeroen's reply about the Sage buildbot is below: Jeroen, do we have an automatic buildbot system for Sage? Depends on what you mean with automatic. We have the buildbot setup at http://build.sagemath.org/sage/waterfall which builds automatically but I still have to change versions by hand and start the builders by hand (in theory, this could be automated but in practice, this is not so easy). Thanks, Jason ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Mon, Feb 13, 2012 at 12:12 AM, Travis Oliphant tra...@continuum.iowrote: I'm wondering about using one of these commercial issue tracking plans for NumPy and would like thoughts and comments.Both of these plans allow Open Source projects to have unlimited plans for free. Free usage of a tool that's itself not open source is not all that different from using Github, so no objections from me. YouTrack from JetBrains: http://www.jetbrains.com/youtrack/features/issue_tracking.html This looks promising. It seems to have good Github integration, and I checked that you can easily export all your issues (so no lock-in). It's a company that isn't going anywhere (I hope), and they do a very nice job with PyCharm. JIRA: http://www.atlassian.com/software/jira/overview/tour/code-integration Haven't looked into this one in much detail. I happen to have a dislike for Confluence (their wiki system), so someone else can say some nice things about JIRA. Haven't tried either tracker though. Anyone with actual experience? What Mark Wiebe said about making it easy to manage the issues quickly and what Eric said about making sure there are interfaces with dense information content really struck chords with me. I have seen a lot of time wasted on issue management with Trac --- time that could be better spent on NumPy.I'd like to make issue management efficient --- even if it means a system separate from GitHub. Issue management is a very important part of the open-source process. While we're at it, our buildbot situation is much worse than our issue tracker situation. This also looks good (and free): http://www.jetbrains.com/teamcity/ Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Mon, Feb 13, 2012 at 12:12 AM, Travis Oliphant tra...@continuum.io wrote: I'm wondering about using one of these commercial issue tracking plans for NumPy and would like thoughts and comments.Both of these plans allow Open Source projects to have unlimited plans for free. Free usage of a tool that's itself not open source is not all that different from using Github, so no objections from me. YouTrack from JetBrains: http://www.jetbrains.com/youtrack/features/issue_tracking.html This looks promising. It seems to have good Github integration, and I checked that you can easily export all your issues (so no lock-in). It's a company that isn't going anywhere (I hope), and they do a very nice job with PyCharm. I do like the team behind JetBrains. And I've seen and heard good things about TeamCity. Thanks for reminding me about the build-bot situation. That is one thing I would like to address sooner rather than later as well. Thanks, -Travis JIRA: http://www.atlassian.com/software/jira/overview/tour/code-integration Haven't looked into this one in much detail. I happen to have a dislike for Confluence (their wiki system), so someone else can say some nice things about JIRA. Haven't tried either tracker though. Anyone with actual experience? What Mark Wiebe said about making it easy to manage the issues quickly and what Eric said about making sure there are interfaces with dense information content really struck chords with me. I have seen a lot of time wasted on issue management with Trac --- time that could be better spent on NumPy. I'd like to make issue management efficient --- even if it means a system separate from GitHub. Issue management is a very important part of the open-source process. While we're at it, our buildbot situation is much worse than our issue tracker situation. This also looks good (and free): http://www.jetbrains.com/teamcity/ Ralf ___ 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
Re: [Numpy-discussion] Issue Tracking
Hi, On Mon, Feb 13, 2012 at 12:44 PM, Travis Oliphant tra...@continuum.io wrote: On Mon, Feb 13, 2012 at 12:12 AM, Travis Oliphant tra...@continuum.io wrote: I'm wondering about using one of these commercial issue tracking plans for NumPy and would like thoughts and comments. Both of these plans allow Open Source projects to have unlimited plans for free. Free usage of a tool that's itself not open source is not all that different from using Github, so no objections from me. YouTrack from JetBrains: http://www.jetbrains.com/youtrack/features/issue_tracking.html This looks promising. It seems to have good Github integration, and I checked that you can easily export all your issues (so no lock-in). It's a company that isn't going anywhere (I hope), and they do a very nice job with PyCharm. I do like the team behind JetBrains. And I've seen and heard good things about TeamCity. Thanks for reminding me about the build-bot situation. That is one thing I would like to address sooner rather than later as well. We've (nipy) got a buildbot collection working OK. If you want to go that way you are welcome to use our machines. It's a somewhat flaky setup though. http://nipy.bic.berkeley.edu/builders I have the impression that the Cython / SAGE team are happy with their Jenkins configuration. Ondrej did some nice stuff on integrating a build with the github pull requests: https://github.com/sympy/sympy-bot Some discussion of buildbot and Jenkins: http://vperic.blogspot.com/2011/05/continuous-integration-and-sympy.html See you, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On 2/13/12 2:56 PM, Matthew Brett wrote: I have the impression that the Cython / SAGE team are happy with their Jenkins configuration. I'm not aware of a Jenkins buildbot system for Sage, though I think Cython uses such a system: https://sage.math.washington.edu:8091/hudson/ We do have a number of systems we build and test Sage on, though I don't think we have continuous integration yet. I've CCd Jeroen Demeyer, who is the current release manager for Sage. Jeroen, do we have an automatic buildbot system for Sage? Thanks, Jason -- Jason Grout ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
Hi, On Mon, Feb 13, 2012 at 2:33 PM, jason-s...@creativetrax.com wrote: On 2/13/12 2:56 PM, Matthew Brett wrote: I have the impression that the Cython / SAGE team are happy with their Jenkins configuration. I'm not aware of a Jenkins buildbot system for Sage, though I think Cython uses such a system: https://sage.math.washington.edu:8091/hudson/ We do have a number of systems we build and test Sage on, though I don't think we have continuous integration yet. I've CCd Jeroen Demeyer, who is the current release manager for Sage. Jeroen, do we have an automatic buildbot system for Sage? Ah - sorry - I was thinking of the Cython system on the SAGE server. Best, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
On Mon, Feb 13, 2012 at 12:56 PM, Matthew Brett matthew.br...@gmail.com wrote: I have the impression that the Cython / SAGE team are happy with their Jenkins configuration. So are we in IPython, thanks to Thomas Kluyver's recent leadership on this front it's now running quite smoothly: https://jenkins.shiningpanda.com/ipython/ I'm pretty sure Thomas is on this list, if you folks have any questions on the details of the setup. Cheers, f ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Issue Tracking
I'm wondering about using one of these commercial issue tracking plans for NumPy and would like thoughts and comments.Both of these plans allow Open Source projects to have unlimited plans for free. JIRA: http://www.atlassian.com/software/jira/overview/tour/code-integration At work we just transitioned off JIRA to TFS. Have to say, for bug tracking, JIRA was a lot better than TFS, not too good as a planning tool though. It is quite customizable and flexible. Nice ability to set up automatic e-mails and such as well. -- --- | Alan K. Jackson| To see a World in a Grain of Sand | | a...@ajackson.org | And a Heaven in a Wild Flower, | | www.ajackson.org | Hold Infinity in the palm of your hand | | Houston, Texas | And Eternity in an hour. - Blake | --- ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Issue Tracking
I'm wondering about using one of these commercial issue tracking plans for NumPy and would like thoughts and comments.Both of these plans allow Open Source projects to have unlimited plans for free. YouTrack from JetBrains: http://www.jetbrains.com/youtrack/features/issue_tracking.html JIRA: http://www.atlassian.com/software/jira/overview/tour/code-integration What Mark Wiebe said about making it easy to manage the issues quickly and what Eric said about making sure there are interfaces with dense information content really struck chords with me. I have seen a lot of time wasted on issue management with Trac --- time that could be better spent on NumPy.I'd like to make issue management efficient --- even if it means a system separate from GitHub. Issue management is a very important part of the open-source process. -Travis ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
