[Numpy-discussion] Issue Tracking

Jason Grout jason-sage@creativetrax....
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 
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 

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 mailing list