How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis
On Saturday, February 11, 2012, Travis Oliphant <travis@continuum.io> wrote:
How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis
This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments. The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves. Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration. Cheers! Ben Root
This is good feedback. It looks like there are 2 concerns: 1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem. 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth). This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins. On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing. So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal. -Travis On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote:
On Saturday, February 11, 2012, Travis Oliphant <travis@continuum.io> wrote:
How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis
This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments.
The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves.
Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration.
Cheers! Ben Root _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Feb 11, 2012 at 1:44 PM, Travis Oliphant <travis@continuum.io>wrote:
This is good feedback.
It looks like there are 2 concerns:
1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem. 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth).
This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins.
On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing.
So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal.
It does present a problem for migrating current trac as a number of the tickets have attachments and we don't want to lose them.
On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote:
How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and
On Saturday, February 11, 2012, Travis Oliphant <travis@continuum.io> wrote: the workflow and integration with commits looks quite good from what I can see.
Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis
This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments.
The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves.
Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration.
Cheers! Ben Root _______________________________________________
Chuck
I think that migration will require some amount of manual intervention, and that this is a perfect opportunity to review the issues which can be part of the NumPy 1.8 work-load. There is an intern I am working with who is looking for something more substantial to do, and this would also be a good opportunity for others who would like to get some experience with NumPy. -Travis On Feb 11, 2012, at 2:53 PM, Charles R Harris wrote:
On Sat, Feb 11, 2012 at 1:44 PM, Travis Oliphant <travis@continuum.io> wrote: This is good feedback.
It looks like there are 2 concerns:
1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem. 2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth).
This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins.
On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing.
So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal.
It does present a problem for migrating current trac as a number of the tickets have attachments and we don't want to lose them.
On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote:
On Saturday, February 11, 2012, Travis Oliphant <travis@continuum.io> wrote:
How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis
This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments.
The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves.
Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration.
Cheers! Ben Root _______________________________________________
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 02/11/2012 10:44 AM, Travis Oliphant wrote:
This is good feedback.
It looks like there are 2 concerns:
1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem.
Not really, in practice. Yes one can use these mechanisms, but they are much clunkier and more obscure than simply being able to attach files via an immediate interface. So the barrier to actual use is high.
2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth).
A third problem is that the entire style of presentation is poorly designed from a use standpoint, in comparison to the sourceforge tracker which mpl used previously. The github tracker appears to have been designed by a graphics person, not a software maintainer. The information density in the issue list is very low; it is impossible to scan a large number of issues at once; there doesn't seem to be any useful sorting and selection mechanism.
This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins.
This doesn't seem so bad to me, at least compared to the *really* bad aspects.
On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing.
So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal.
The one good thing about the github tracker is its integration with the code. Otherwise it is still just plain bad, and will remain so until it is given an information-dense tabular interface, with things like initiation date, last update, category, priority, etc. Down with whitespace and icons! We need information! Eric
-Travis
On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote:
On Saturday, February 11, 2012, Travis Oliphant <travis@continuum.io <mailto:travis@continuum.io>> wrote:
How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis
This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments.
The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves.
Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration.
Cheers! Ben Root _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org> http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 2/11/12 3:12 PM, Eric Firing wrote:
A third problem is that the entire style of presentation is poorly designed from a use standpoint, in comparison to the sourceforge tracker which mpl used previously. The github tracker appears to have been designed by a graphics person, not a software maintainer. The information density in the issue list is very low; it is impossible to scan a large number of issues at once; there doesn't seem to be any useful sorting and selection mechanism.
I agree. Also, another thing that is really frustrating is that the issue number does not appear in the listing. So when you are trying to refer to another issue, and try finding it by scanning the list, you have to mouse over the title and extract the information mentally from the url. Google code issues are much, much better in these regards. Jason
On Sat, Feb 11, 2012 at 3:12 PM, Eric Firing <efiring@hawaii.edu> wrote:
On 02/11/2012 10:44 AM, Travis Oliphant wrote:<snip>
2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth).
A third problem is that the entire style of presentation is poorly designed from a use standpoint, in comparison to the sourceforge tracker which mpl used previously. The github tracker appears to have been designed by a graphics person, not a software maintainer. The information density in the issue list is very low; it is impossible to scan a large number of issues at once; there doesn't seem to be any useful sorting and selection mechanism.
The lack of a tabular way to mass-edit bugs is one of my biggest problems with the current trac. One thing that ideally we could do regularly is to rapidly triage 100s of bugs. Currently trac requires you to go through them one by one, like harvesting wheat with a scythe instead of a combine. Users who are mentioned in a lot of tickets also get spammed by a large number of message, instead of getting a single summary update of all the triaging that was done. Does the github bug tracker have a good story about mass bug-updating? -Mark
This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins.
This doesn't seem so bad to me, at least compared to the *really* bad aspects.
On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing.
So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal.
The one good thing about the github tracker is its integration with the code. Otherwise it is still just plain bad, and will remain so until it is given an information-dense tabular interface, with things like initiation date, last update, category, priority, etc. Down with whitespace and icons! We need information!
Eric
-Travis
On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote:
On Saturday, February 11, 2012, Travis Oliphant <travis@continuum.io <mailto:travis@continuum.io>> wrote:
How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see. Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github Are there others? -Travis
This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments.
The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves.
Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration.
Cheers! Ben Root _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org> http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sat, Feb 11, 2012 at 9:49 PM, Mark Wiebe <mwwiebe@gmail.com> wrote:
On Sat, Feb 11, 2012 at 3:12 PM, Eric Firing <efiring@hawaii.edu> wrote:
On 02/11/2012 10:44 AM, Travis Oliphant wrote:<snip>
2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth).
A third problem is that the entire style of presentation is poorly designed from a use standpoint, in comparison to the sourceforge tracker which mpl used previously. The github tracker appears to have been designed by a graphics person, not a software maintainer. The information density in the issue list is very low; it is impossible to scan a large number of issues at once; there doesn't seem to be any useful sorting and selection mechanism.
The lack of a tabular way to mass-edit bugs is one of my biggest problems with the current trac. One thing that ideally we could do regularly is to rapidly triage 100s of bugs. Currently trac requires you to go through them one by one, like harvesting wheat with a scythe instead of a combine. Users who are mentioned in a lot of tickets also get spammed by a large number of message, instead of getting a single summary update of all the triaging that was done.
Does the github bug tracker have a good story about mass bug-updating?
Github is better than trac on that issue: updating the milestone for many bugs at once is simple. You don't have priorities, etc…, though. The Rest API also enables in principle to write tools to automate the repetitive tasks. David
11.02.2012 20:44, Travis Oliphant kirjoitti:
How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see.
The lack of attachments is the main problem with this transition. It's not so seldom that numerical input data or scripts demonstrating an issue come useful. This is probably less of an issue for Numpy than for Scipy, though. Pauli
On Sat, Feb 11, 2012 at 12:36 PM, Pauli Virtanen <pav@iki.fi> wrote:
The lack of attachments is the main problem with this transition. It's not so seldom that numerical input data or scripts demonstrating an issue come useful. This is probably less of an issue for Numpy than for Scipy, though.
We've taken to using gist for scripts/data and free image hosting sites for screenshots, using <img src="http://.... /img> to show the screenshot in the bug report when relevant. Not always ideal, but it does get the job done, and actually with gist, it's kind of nice that the 'attachment' can evolve with version control too. The lack of real priorities *is* a hassle, at least for me. I understand the rationale behind a very simple UI and unstructured labels, but priority is such a central concept to bug tracking that its absence is a shortcoming, pure and simple. In summary, in IPython we've been using the gh tracker for almost 2 years, and since the updates to issues 2.0, with milestones and individual assignee fields, they are quite serviceable. In the balance, I feel the benefits of tight integration with the rest of the site outweigh the limitations, though I'll be very happy if those limitations are removed in future upgrades to the site. Cheers, f
On Sat, Feb 11, 2012 at 21:54, Fernando Perez <fperez.net@gmail.com> wrote:
On Sat, Feb 11, 2012 at 12:36 PM, Pauli Virtanen <pav@iki.fi> wrote:
The lack of attachments is the main problem with this transition. It's not so seldom that numerical input data or scripts demonstrating an issue come useful. This is probably less of an issue for Numpy than for Scipy, though.
We've taken to using gist for scripts/data and free image hosting sites for screenshots, using
<img src="http://.... /img>
CellProfiler recently transitioned to Github issues from an internal Jira server. Since most of our bug reports require some sort of attachment to be useful, we put up a page at cellprofiler.org/issues that uses Github's authentication API to file bugs with attachments. The bug report itself gets added to the github issues, the attachment gets stored on our server, and links to the latter appear in the former. bug page: http://cellprofiler.org/issues/ example issue: https://github.com/CellProfiler/CellProfiler/issues/260 It was pretty simple to put together (a few hours by one developer). The need for a github account keeps it from being spammed. If that's too much of a bar, I expect it could have a branch-cut in behavior: witha github account, the report goes straight into the Github issues, otherwise, it gets queued for review and mail sent to some (hopefully low-traffic) list. Ray Jones
On Wed, Feb 15, 2012 at 12:11 PM, Thouis (Ray) Jones <thouis@gmail.com>wrote:
On Sat, Feb 11, 2012 at 21:54, Fernando Perez <fperez.net@gmail.com> wrote:
On Sat, Feb 11, 2012 at 12:36 PM, Pauli Virtanen <pav@iki.fi> wrote:
The lack of attachments is the main problem with this transition. It's not so seldom that numerical input data or scripts demonstrating an issue come useful. This is probably less of an issue for Numpy than for Scipy, though.
We've taken to using gist for scripts/data and free image hosting sites for screenshots, using
<img src="http://.... /img>
CellProfiler recently transitioned to Github issues from an internal Jira server.
In another thread Jira was proposed as an alternative to Trac. Can you point out some of its strengths and weaknesses, and tell us why you decided to move away from it? Thanks, Ralf
Since most of our bug reports require some sort of attachment to be useful, we put up a page at cellprofiler.org/issues that uses Github's authentication API to file bugs with attachments. The bug report itself gets added to the github issues, the attachment gets stored on our server, and links to the latter appear in the former.
bug page: http://cellprofiler.org/issues/ example issue: https://github.com/CellProfiler/CellProfiler/issues/260
It was pretty simple to put together (a few hours by one developer). The need for a github account keeps it from being spammed. If that's too much of a bar, I expect it could have a branch-cut in behavior: witha github account, the report goes straight into the Github issues, otherwise, it gets queued for review and mail sent to some (hopefully low-traffic) list.
Ray Jones _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Thu, Feb 16, 2012 at 19:25, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
In another thread Jira was proposed as an alternative to Trac. Can you point out some of its strengths and weaknesses, and tell us why you decided to move away from it?
The two primary reasons were that our Jira server was behind a firewall and we wanted to open it up, and the integration with github, where we were moving our source. My own impression is that Jira is much more complicated. It was nice that it was integrated with Fisheye and some reporting tools, but I found them so complicated to deal with that I usually didn't go beyond "show me my bugs", some bulk bug editing, and adding users to projects. As a group, we had difficulties keeping track of how we were indicating priority and planned work, even with wiki pages to tell us what we intended the different labels to mean. Jira's integration with other tools (Fisheye, Crucible) was useful in some ways, but in no way critical. There were all kinds of reports (LOC, bug count, etc.) that one could get from these, but nothing that couldn't be created with pylab and a free hour or two. I like github's issues for their simplicity and the http-based API. We miss having direct attachements, but we have a workaround. It would be nice if the github issues page were more customizable, but with the API, a motivated group could create whatever frontend they wanted. Github's issues remind me of python, Jira reminded me of Java. I guess Jira would be more suited to a large developments effort with multiple groups of programmers, which we were not. Moving bugs from Jira to github wasn't too bad (we dropped most of the metadata, except for our current/next/future label for which release fixes would go into). I think it would be easier to move from github to Jira, primarily because github has fewer possible bits of metadata on each bug. As I said, I avoided using Jira for anything really complicated, so perhaps I just needed to spend more time with it. My opinion should probably not be given undue weight.
On Thu, Feb 16, 2012 at 10:20 PM, Thouis (Ray) Jones <thouis@gmail.com>wrote:
In another thread Jira was proposed as an alternative to Trac. Can you
On Thu, Feb 16, 2012 at 19:25, Ralf Gommers <ralf.gommers@googlemail.com> wrote: point
out some of its strengths and weaknesses, and tell us why you decided to move away from it?
....
Jira reminded me of Java.
OK, you convinced me:) Ralf
On Thu, Feb 16, 2012 at 4:32 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Thu, Feb 16, 2012 at 10:20 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote:
On Thu, Feb 16, 2012 at 19:25, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
In another thread Jira was proposed as an alternative to Trac. Can you point out some of its strengths and weaknesses, and tell us why you decided to move away from it?
....
Jira reminded me of Java.
OK, you convinced me:)
Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Having just created a NumPy ticket (http://projects.scipy.org/numpy/ticket/2065) I feel pretty strongly about moving the issue tracker to GitHub--the lack of attachments is easy to work around. I think it will help a lot for building more community engagement with the development process. My experience using it with pandas has been very positive-- I have churned through around 700 issues over the last 12 months and I've never felt like it's gotten in my way (except for the occasional CSS/JS bugs in the web UI). - Wes
On 2/11/12 1:44 PM, Travis Oliphant wrote:
How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see.
Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github
Are there others?
Are there any good github trac plugins? For example: http://davglass.lighthouseapp.com/projects/21212/home http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe useful) Thanks, Jason
11.02.2012 22:02, Jason Grout kirjoitti: [clip]
Are there any good github trac plugins? For example:
http://davglass.lighthouseapp.com/projects/21212/home
http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe useful)
The Numpy & Scipy Trac is currently running on this: https://github.com/pv/githubsimple-trac
participants (12)
-
Benjamin Root -
Charles R Harris -
David Cournapeau -
Eric Firing -
Fernando Perez -
Jason Grout -
Mark Wiebe -
Pauli Virtanen -
Ralf Gommers -
Thouis (Ray) Jones -
Travis Oliphant -
Wes McKinney