[Numpy-discussion] Issue Tracking
Mon Apr 30 22:14:55 CDT 2012
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
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
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.
More information about the NumPy-Discussion