On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant <[email protected]>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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
