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
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. 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. 3. No attachments for issues (screenshots, supporting documents, etc.). Having API access to data won't help you here. 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. 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. 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. How does, for example, the JIRA github connector work? Does it pull in code comments, etc.? Anyways, I'm not a regular contributor to numpy, but I have been trying to get used to the github tracker for about a year now, and I just keep getting more frustrated at it. I suppose the biggest frustrating part about it is that it is closed source, so even if I did want to scratch an itch, I can't. 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. Thanks, Jason
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 can improve (and tools can be written which improve the experience).
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.
Yes, it looks like you can group via labels, milestones, and "your" issues. This is also something that can be over-come with tools that use the github API. It would be good to hear from users of the IPython github issue tracker to see how they like it "in the wild". How problematic are these issues in practice. Does it reduce or increase the participation in issue tracking both by users and by developers. Thanks, -Travis
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.
How does, for example, the JIRA github connector work? Does it pull in code comments, etc.?
Anyways, I'm not a regular contributor to numpy, but I have been trying to get used to the github tracker for about a year now, and I just keep getting more frustrated at it. I suppose the biggest frustrating part about it is that it is closed source, so even if I did want to scratch an itch, I can't.
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.
Thanks,
Jason _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant <travis@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 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 can improve (and tools can be written which improve the experience).
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.
Yes, it looks like you can group via labels, milestones, and "your" issues. This is also something that can be over-come with tools that use the github API.
It would be good to hear from users of the IPython github issue tracker to see how they like it "in the wild". How problematic are these issues in practice. Does it reduce or increase the participation in issue tracking both by users and by developers.
Thanks,
-Travis
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.
How does, for example, the JIRA github connector work? Does it pull in code comments, etc.?
Anyways, I'm not a regular contributor to numpy, but I have been trying to get used to the github tracker for about a year now, and I just keep getting more frustrated at it. I suppose the biggest frustrating part about it is that it is closed source, so even if I did want to scratch an itch, I can't.
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.
I'm thinking we could do worse than simply take Ralf's top pick. Github definitely sounds a bit clunky for issue tracking, and while we could put together workarounds, I think Jason's point about the overall frustration is telling. And while we could, maybe, put together tools to work with it, I think what we want is something that works out of the box. Implementing workarounds for a frustrating system doesn't seem the best use of developer time. Chuck
On Tue, May 1, 2012 at 9:12 AM, Charles R Harris <charlesr.harris@gmail.com>wrote:
On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant <travis@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 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 can improve (and tools can be written which improve the experience).
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.
Yes, it looks like you can group via labels, milestones, and "your" issues. This is also something that can be over-come with tools that use the github API.
It would be good to hear from users of the IPython github issue tracker to see how they like it "in the wild". How problematic are these issues in practice. Does it reduce or increase the participation in issue tracking both by users and by developers.
Thanks,
-Travis
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.
How does, for example, the JIRA github connector work? Does it pull in code comments, etc.?
Anyways, I'm not a regular contributor to numpy, but I have been trying to get used to the github tracker for about a year now, and I just keep getting more frustrated at it. I suppose the biggest frustrating part about it is that it is closed source, so even if I did want to scratch an itch, I can't.
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.
I'm thinking we could do worse than simply take Ralf's top pick. Github definitely sounds a bit clunky for issue tracking, and while we could put together workarounds, I think Jason's point about the overall frustration is telling. And while we could, maybe, put together tools to work with it, I think what we want is something that works out of the box. Implementing workarounds for a frustrating system doesn't seem the best use of developer time.
Having looked at the IPython issues and Jason's example, it's still my impression that Github is inferior to Trac/Redmine as a bug tracker -- but not as much as I first thought. The IPython team has managed to make it work quite well (assuming you can stand the multi-colored patchwork of labels...). At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) 2. mass editing of tickets (good to have) 3. usable API (good to have) 4. various ideas/issues mentioned at http://projects.scipy.org/numpy/wiki/ImprovingIssueWorkflow Note that Github does solve 1, 2 and 3 (as does Redmine). It does come with some new problems that require workarounds, but we can probably live with them. I'm not convinced that being on Github will actually get more eyes on the tickets, but there certainly won't be less. 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. 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. Ralf
On Tue, May 1, 2012 at 1:34 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Tue, May 1, 2012 at 9:12 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant <travis@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 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 can improve (and tools can be written which improve the experience).
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.
Yes, it looks like you can group via labels, milestones, and "your" issues. This is also something that can be over-come with tools that use the github API.
It would be good to hear from users of the IPython github issue tracker to see how they like it "in the wild". How problematic are these issues in practice. Does it reduce or increase the participation in issue tracking both by users and by developers.
Thanks,
-Travis
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.
How does, for example, the JIRA github connector work? Does it pull in code comments, etc.?
Anyways, I'm not a regular contributor to numpy, but I have been trying to get used to the github tracker for about a year now, and I just keep getting more frustrated at it. I suppose the biggest frustrating part about it is that it is closed source, so even if I did want to scratch an itch, I can't.
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.
I'm thinking we could do worse than simply take Ralf's top pick. Github definitely sounds a bit clunky for issue tracking, and while we could put together workarounds, I think Jason's point about the overall frustration is telling. And while we could, maybe, put together tools to work with it, I think what we want is something that works out of the box. Implementing workarounds for a frustrating system doesn't seem the best use of developer time.
Having looked at the IPython issues and Jason's example, it's still my impression that Github is inferior to Trac/Redmine as a bug tracker -- but not as much as I first thought. The IPython team has managed to make it work quite well (assuming you can stand the multi-colored patchwork of labels...).
At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) 2. mass editing of tickets (good to have) 3. usable API (good to have) 4. various ideas/issues mentioned at http://projects.scipy.org/numpy/wiki/ImprovingIssueWorkflow
Note that Github does solve 1, 2 and 3 (as does Redmine). It does come with some new problems that require workarounds, but we can probably live with them. I'm not convinced that being on Github will actually get more eyes on the tickets, but there certainly won't be less.
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.
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.
Redmine looks to offer a lot for project management, not just issue tracking. We don't do much in the way of project management, but that may well be a case of not having the tools, opportunity, and training. Once those tools are available we might find a use for them. I think Redmine offers more open ended opportunity for improvements for the project as a whole than github, which seems something of a dead end in that regard. The fact that Redmine also supports multiple projects might make it a better fit with the goals of NumFocus over the long run. Chuck
On Tue, May 1, 2012 at 2:17 PM, Charles R Harris <charlesr.harris@gmail.com>wrote:
On Tue, May 1, 2012 at 1:34 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Tue, May 1, 2012 at 9:12 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant <travis@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 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 can improve (and tools can be written which improve the experience).
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.
Yes, it looks like you can group via labels, milestones, and "your" issues. This is also something that can be over-come with tools that use the github API.
It would be good to hear from users of the IPython github issue tracker to see how they like it "in the wild". How problematic are these issues in practice. Does it reduce or increase the participation in issue tracking both by users and by developers.
Thanks,
-Travis
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.
How does, for example, the JIRA github connector work? Does it pull in code comments, etc.?
Anyways, I'm not a regular contributor to numpy, but I have been trying to get used to the github tracker for about a year now, and I just keep getting more frustrated at it. I suppose the biggest frustrating part about it is that it is closed source, so even if I did want to scratch an itch, I can't.
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.
I'm thinking we could do worse than simply take Ralf's top pick. Github definitely sounds a bit clunky for issue tracking, and while we could put together workarounds, I think Jason's point about the overall frustration is telling. And while we could, maybe, put together tools to work with it, I think what we want is something that works out of the box. Implementing workarounds for a frustrating system doesn't seem the best use of developer time.
Having looked at the IPython issues and Jason's example, it's still my impression that Github is inferior to Trac/Redmine as a bug tracker -- but not as much as I first thought. The IPython team has managed to make it work quite well (assuming you can stand the multi-colored patchwork of labels...).
At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) 2. mass editing of tickets (good to have) 3. usable API (good to have) 4. various ideas/issues mentioned at http://projects.scipy.org/numpy/wiki/ImprovingIssueWorkflow
Note that Github does solve 1, 2 and 3 (as does Redmine). It does come with some new problems that require workarounds, but we can probably live with them. I'm not convinced that being on Github will actually get more eyes on the tickets, but there certainly won't be less.
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.
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.
Redmine looks to offer a lot for project management, not just issue tracking. We don't do much in the way of project management, but that may well be a case of not having the tools, opportunity, and training. Once those tools are available we might find a use for them. I think Redmine offers more open ended opportunity for improvements for the project as a whole than github, which seems something of a dead end in that regard. The fact that Redmine also supports multiple projects might make it a better fit with the goals of NumFocus over the long run.
To expand on this a bit. At some point you will need to generate timelines, reports, and statistics in order to sell the project to people with real money. It looks like Redmine would help a lot in this regard. Chuck
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.harris@gmail.com> wrote:
On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant <travis@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 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 can improve (and tools can be written which improve the experience).
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.
Yes, it looks like you can group via labels, milestones, and "your" issues. This is also something that can be over-come with tools that use the github API.
It would be good to hear from users of the IPython github issue tracker to see how they like it "in the wild". How problematic are these issues in practice. Does it reduce or increase the participation in issue tracking both by users and by developers.
Thanks,
-Travis
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.
How does, for example, the JIRA github connector work? Does it pull in code comments, etc.?
Anyways, I'm not a regular contributor to numpy, but I have been trying to get used to the github tracker for about a year now, and I just keep getting more frustrated at it. I suppose the biggest frustrating part about it is that it is closed source, so even if I did want to scratch an itch, I can't.
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.
I'm thinking we could do worse than simply take Ralf's top pick. Github definitely sounds a bit clunky for issue tracking, and while we could put together workarounds, I think Jason's point about the overall frustration is telling. And while we could, maybe, put together tools to work with it, I think what we want is something that works out of the box. Implementing workarounds for a frustrating system doesn't seem the best use of developer time.
Having looked at the IPython issues and Jason's example, it's still my impression that Github is inferior to Trac/Redmine as a bug tracker -- but not as much as I first thought. The IPython team has managed to make it work quite well (assuming you can stand the multi-colored patchwork of labels...).
At this point it's probably good to look again at the problems we want to solve: 1. responsive user interface (must absolutely have) 2. mass editing of tickets (good to have) 3. usable API (good to have) 4. various ideas/issues mentioned at http://projects.scipy.org/numpy/wiki/ImprovingIssueWorkflow
Note that Github does solve 1, 2 and 3 (as does Redmine). It does come with some new problems that require workarounds, but we can probably live with them. I'm not convinced that being on Github will actually get more eyes on the tickets, but there certainly won't be less.
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.
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.
Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
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
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
On Tue, May 1, 2012 at 7:48 PM, Pauli Virtanen <pav@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=apply&status=needs_decision&status=needs_info&status=needs_review&status=needs_work&status=new&status=reopened&component=scipy.stats&order=status to something like this https://github.com/ipython/ipython/issues?direction=desc&labels=windows&page=1&sort=created&state=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
On Tue, May 1, 2012 at 6:18 PM, <josef.pktd@gmail.com> wrote:
On Tue, May 1, 2012 at 7:48 PM, Pauli Virtanen <pav@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
to something like this
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
On Tue, May 1, 2012 at 5:24 PM, Charles R Harris <charlesr.harris@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
On Tue, May 1, 2012 at 8:29 PM, Fernando Perez <fperez.net@gmail.com> wrote:
On Tue, May 1, 2012 at 5:24 PM, Charles R Harris <charlesr.harris@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
On Tue, May 1, 2012 at 6:04 PM, <josef.pktd@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
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
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen <pav@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
On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen <pav@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
On Wed, May 2, 2012 at 9:48 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen <pav@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
On Wed, May 2, 2012 at 11:25 PM, Wes McKinney <wesmckinn@gmail.com> wrote:
On Wed, May 2, 2012 at 9:48 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers <
ralf.gommers@googlemail.com>
wrote:
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen <pav@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
On Sat, May 5, 2012 at 1:28 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Wed, May 2, 2012 at 11:25 PM, Wes McKinney <wesmckinn@gmail.com> wrote:
On Wed, May 2, 2012 at 9:48 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers <
ralf.gommers@googlemail.com>
wrote:
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen <pav@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
On May 5, 2012, at 2:28 PM, Ralf Gommers wrote:
On Wed, May 2, 2012 at 11:25 PM, Wes McKinney <wesmckinn@gmail.com> wrote: On Wed, May 2, 2012 at 9:48 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen <pav@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
On Sat, May 5, 2012 at 10:19 PM, Travis Oliphant <travis@continuum.io>wrote:
On May 5, 2012, at 2:28 PM, Ralf Gommers wrote:
On Wed, May 2, 2012 at 11:25 PM, Wes McKinney <wesmckinn@gmail.com> wrote:
On Wed, May 2, 2012 at 9:48 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers <
ralf.gommers@googlemail.com>
wrote:
On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen <pav@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.
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
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
On Sat, May 5, 2012 at 8:50 PM, Benjamin Root <ben.root@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
On Saturday, May 5, 2012, Charles R Harris wrote:
On Sat, May 5, 2012 at 8:50 PM, Benjamin Root <ben.root@ou.edu<javascript:_e({}, 'cvml', 'ben.root@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.
+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.harris@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
On 5/1/12 1:52 AM, Travis Oliphant wrote:
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.
Sure, it is possible, but it takes the hierarchal information out of the picture, so we lose semantic meaning. It is possible to add two different conflicting priorities, for example, and you can't enforce a certain workflow like you can with trac states, for example. Not to mention that the only filtering you can do on labels is by clicking the labels on the left, which is an "AND" filter. How do you search for tickets that are labeled priority-critical OR priority-high?
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?)
I just double-checked. This issue started out as an issue, then I "attached" code by using the API to attach a branch to the issue [1]. The result is: https://github.com/sagemath/sagecell/pull/300 You'll notice that there are no tags on the right side, and as a project admin, I don't see any way to add them either. If you go to the list view: https://github.com/sagemath/sagecell/issues?milestone=6&sort=updated&state=closed you actually *do* see two tags attached. I *can* change labels in the list view, if it's the list view for *issues*. If I view the same "issue turned pull request" in the pull request list view: https://github.com/sagemath/sagecell/pulls (you have to click "closed"---apparently clicking "closed" doesn't change the URL, so I can't give you a link to that listing view...) then I see at the top (right now) "pull request 300" (though in the pull request view, you don't see the 300 to the side, like you see in the issue view). Of course, like other pull requests, you can't attach labels in the pull request list view. From the above, I get the idea that github does not really support attaching code to issues, though it is technically possible through the API. To me, that means that every problem has at least two tickets (an issue and a pull request), and you have to make sure to manually close and sync one with the other, and the discussion is split up between the two tickets. [1] One of my students has a short script to encapsulate doing this via the API: https://gist.github.com/2156799
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.
Sure, it's possible, but like you said, it splits up the conversation to have parts of it hosted elsewhere.
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 can improve (and tools can be written which improve the experience).
Yep, so the question is: how much of a bug tracker and common reports are you willing to rebuild on the github infrastructure, or is it easier to use something with all of this built in that also has git/github connections.
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.
Yes, it looks like you can group via labels, milestones, and "your" issues. This is also something that can be over-come with tools that use the github API.
You can filter on those, but I don't see how to group on those (i.e., have a big listing of everything, but group the results together based on their labels or their milestones, etc. It makes it much harder to get a big-picture view of lots of issues and how they are related. Again, of course you can write tools to do this with the github API, but again, how much existing bug-tracker functionality do you want to reimplement? By the way: are people keeping a backup of the issues, etc.? You can get a data dump of, for example, the full issue database. It seems like it would make sense for a project, like IPython, to periodically download all of its data to make an off-site backup not tied to a commercial company.
It would be good to hear from users of the IPython github issue tracker to see how they like it "in the wild". How problematic are these issues in practice. Does it reduce or increase the participation in issue tracking both by users and by developers.
I agree; it would be good to hear from someone with wider and broader experience with the github tracker on these issues. Thanks, Jason
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
Hi folks, sorry for not jumping in before, swamped with deadlines... On Mon, Apr 30, 2012 at 8:14 PM, Jason Grout <jason-sage@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 benefit to having a smooth flow of information in one environment. People get more efficient with the toolchain (I've learned markdown without even trying, simply from gradually doing nicer and nicer reports as I use the system), and there's a 'network effect' at play here. On Mon, Apr 30, 2012 at 11:16 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
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.
This also bothers me quite a bit. I'd like my email thread to be a full record of the ticket, not just other people's responses. Furthermore, if you use markdown in an email reply, for some reason they don't render it on the site anymore. So I end up using the site directly most of the time so the issue reads nicely formatted.
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
This one I think is a no-brainer, at least the website pages. For that, the system using dual repos and a web team on github, like we do, is simply perfect. I see no reason whatsoever not to do this. In summary, I think we made the right decision for IPython with using GHI, and I do think that the simplicity of the tool does also help in focusing on writing more code instead of staring at reports of open issues :) But I do wish dearly they made improvements to some of the system's limitations listed above, because several of them are truly annoying to have to put up with. As for numpy/scipy, it's hard to say. The view of people like Ralf, Pauli, Chuck and others is what matters most here. If they are going to get so aggravated by the system's limitations that they don't want to work on the project, that's not a risk worth taking. On the other hand, I'm famous for being persnickety about my tools (Brian says IPython is the embodiment in source code of my untreated OCD :), and yet I've managed to adapt. So better souls than me can probably do it too ;) 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. tl,dr; GHI is a net positive for IPython, but it does have real annoyances you can't just wish away. Best, f
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
On Tue, May 1, 2012 at 1:36 PM, Jason Grout <jason-sage@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
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
On Mon, Apr 30, 2012 at 5:31 PM, Travis Oliphant <travis@continuum.io>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.
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
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
On Mon, Apr 30, 2012 at 10:14 PM, Travis Oliphant <travis@continuum.io>wrote:
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 significant factor in the choice. And that also argues for making a pick pretty soon, there is no point in having folks spending a few more weeks just trying things out. Of course, the main problem with trac, which a better system won't solve, is having the time to deal with the issues. Fedora uses bugzilla, and after a ticket has aged sufficiently they simply close it on principal even if it hasn't been officially closed. No doubt a lot of things do get fixed without anyone connecting it to a specific ticket. Maybe we need to have a collection of failing tests, not just tests for things that have been fixed. If I could hit a button and send the problem code into a failure repository, formatted for nose and with a number and back link, that would be great. Maybe not up there with a flying car but certainly a close second. Something like that could even be part of a continuous integration system. Chuck
On Tue, May 1, 2012 at 12:16 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
On Mon, Apr 30, 2012 at 10:14 PM, Travis Oliphant <travis@continuum.io>wrote:
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 significant factor in the choice. And that also argues for making a pick pretty soon, there is no point in having folks spending a few more weeks just trying things out.
Of course, the main problem with trac, which a better system won't solve, is having the time to deal with the issues. Fedora uses bugzilla, and after a ticket has aged sufficiently they simply close it on principal even if it hasn't been officially closed. No doubt a lot of things do get fixed without anyone connecting it to a specific ticket. Maybe we need to have a collection of failing tests, not just tests for things that have been fixed. If I could hit a button and send the problem code into a failure repository, formatted for nose and with a number and back link, that would be great. Maybe not up there with a flying car but certainly a close second. Something like that could even be part of a continuous integration system.
I'll add that tickets don't get looked at as often as they should and that is an important consideration. Having them up on github might help in that regard. Chuck
participants (10)
-
Benjamin Root -
Charles R Harris -
Fernando Perez -
Jason Grout -
josef.pktd＠gmail.com -
Paul Ivanov -
Pauli Virtanen -
Ralf Gommers -
Travis Oliphant -
Wes McKinney