<br><br><div class="gmail_quote">On Tue, May 1, 2012 at 12:52 AM, Travis Oliphant <span dir="ltr"><<a href="mailto:travis@continuum.io" target="_blank">travis@continuum.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div><div class="h5"><div>On Apr 30, 2012, at 10:14 PM, Jason Grout wrote:</div><br><blockquote type="cite"><div>On 4/30/12 6:31 PM, Travis Oliphant wrote:<br><blockquote type="cite">
Hey all,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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:<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">1) Redmine<br></blockquote><blockquote type="cite">2) Trac<br></blockquote><blockquote type="cite">3) Github<br></blockquote><blockquote type="cite">
<br></blockquote><blockquote type="cite">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.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Comments, concerns?<br></blockquote><br>I've been pretty impressed with the lemonade that the IPython folks have <br>made out of what I see as pretty limiting shortcomings of the github <br>
issue tracker.  I've been trying to use it for a much smaller project <br>(<a href="https://github.com/sagemath/sagecell/" target="_blank">https://github.com/sagemath/sagecell/</a>), and it is a lot harder, in my <br>
(somewhat limited) experience, than using trac or the google issue <br>tracker.  None of these issues seems like it would be too hard to solve, <br>but since we don't even have the source to the tracker, we're somewhat <br>
at github's mercy for any improvements.  Github does have a very nice <br>API for interacting with the data, which somewhat makes up for some of <br>the severe shortcomings of the web interface.<br><br>In no particular order, here are a few that come to mind immediately:<br>
<br>1. No key:value pairs for labels (Fernando brought this up a long time <br>ago, I think).  This is brilliant in Google code's tracker, and allows <br>for custom fields that help in tracking workflow (like status, priority, <br>
etc.).  Sure, you can do what the IPython folks are doing and just <br>create labels for every possible status, but that's unwieldy and takes a <br>lot of discipline to maintain.  Which means it takes a lot of developer <br>
time or it becomes inconsistent and not very useful.<br></div></blockquote><div><br></div></div></div><div>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.</div>
<div class="im"><br><blockquote type="cite"><div><br>2. The disjointed relationship between pull requests and issues.  They <br>share numberings, for example, and both support discussions, etc.  If <br>you use the API, you can submit code to an issue, but then the issue <br>
becomes a pull request, which means that all labels on the issue <br>disappear from the web interface (but you can still manage to set labels <br>using the list view of the issue tracker, if I recall correctly).  If <br>you don't attach code to issues, it means that every issue is duplicated <br>
in a pull request, which splits the conversation up between an issue <br>ticket and a pull request ticket.<br></div></blockquote><div><br></div></div><div>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?)</div>
<div class="im"><br><blockquote type="cite"><div><br>3. No attachments for issues (screenshots, supporting documents, etc.). <br>  Having API access to data won't help you here.<br></div></blockquote><div><br></div></div>
<div>Using gists and references to gists can overcome this.   Also using an attachment service like <a href="http://uploading.com/" target="_blank">http://uploading.com/</a> or dropbox makes this problem less of an issue really. </div>
<div class="im"><div><br></div><blockquote type="cite"><div><br>4. No custom queries.  We love these in the Sage trac instance; since we <br>have full access to the database, we can run any sort of query we want. <br>  With API data access, you can build your own queries, so maybe this <br>
isn't insurmountable.<br></div></blockquote><div><br></div></div><div>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).  </div>
<div class="im"><br><blockquote type="cite"><div><br>5. Stylistically, the webpage is not very dense on information.  I get <br>frustrated when trying to see the issues because they only come 25 at a <br>time, and never grouped into any sort of groupings, and there are only 3 <br>
options for sorting issues.  Compare the very nice, dense layout of <br>Google Code issues or bitbucket.  Google Code issues also lets you <br>cross-tabulate the issues so you can quickly triage them.  Compare also <br>the pretty comprehensive options for sorting and grouping things in trac.<br>
</div></blockquote><div><br></div></div><div>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.  </div>
<div><br></div><div><br></div><div>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.  </div>
<div><br></div><div>Thanks,  </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Travis</div></font></span><div class="im"><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><div><br>
6. Side-by-side diffs are nice to have, and I believe bitbucket and <br>google code both have them.  Of course, this isn't a deal-breaker <br>because you can always pull the branch down, but it would be nice to <br>have, and there's not really a way we can put it into the github tracker <br>
ourselves.<br><br>How does, for example, the JIRA github connector work?  Does it pull in <br>code comments, etc.?<br><br>Anyways, I'm not a regular contributor to numpy, but I have been trying <br>to get used to the github tracker for about a year now, and I just keep <br>
getting more frustrated at it.  I suppose the biggest frustrating part <br>about it is that it is closed source, so even if I did want to scratch <br>an itch, I can't.<br><br>That said, it is nice to have code and dev conversations happening in <br>
one place.  There are great things about github issues, of course.  But <br>I'm not so sure, for me, that they outweigh some of the administrative <br>issues listed above.<br><br></div></blockquote></div></div></div></blockquote>
<div><br>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. <br>
<br>Chuck<br></div><br></div>