<br><br><div class="gmail_quote">On Mon, Apr 30, 2012 at 10:14 PM, 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 class="im"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
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>


<br></blockquote><div><br>There is a group where I work that purchased the enterprise version of github. But they still use trac. I think Ralf's opinion should count for a fair amount here, since the tracker is important for releases and backports. Having a good connection between commits and tickets is also very helpful, although sticking with github might be better there. The issue tracker isn't really intended as social media and I find the notifications from trac sufficient.<br>

<br>Chuck <br></div></div></blockquote><div><br></div><div><br></div></div>I think Ralf and your opinion on this is *huge*.      It seems that Issue tracking is at the heart of "social media" activity, though, because you need people to submit issues and you need people to respond to those issues in a timely way.    And it is ideal if the dialogue that might ensue pursuant to that activity is discoverable via search and linking. </div>
<div><br></div><div>But the issue tracking problem really is dividable into separate work flows: </div><div><span style="white-space:pre-wrap">     </span></div><div><span style="white-space:pre-wrap"> </span>1) The submission of the issue (here things like ease-of-entry and attaching files is critical)</div>
</div></blockquote><div><br>Yes, trac does allow attachments, but numpy trac locks up pretty often and I don't see why I should be locked out from submitting a comment just because someone else has made a comment while I've been typing. That said, trac does seem more responsive lately (thanks Pauli).<br>
<br>I also don't find the trac interface attractive to look at, but it works. I could live without attachments, but they can be handy for scripts that demonstrate bugs and so on. As for fixes, I think we want to encourage pull requests rather than attached patches, but it might take a while before everyone is comfortable with that procedure.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span style="white-space:pre-wrap">      </span>2) The dialogue around the issue (developer comments on it and any discussion that ensues)</div>
</div></blockquote><div><br>I find the trac email notifications pretty good in that regard, although it would be nice to have everything in one place. The main issue I have, actually, is that github won't send me everything. I want to see every posted comment and every commit show up in the mail, including my own comments. The RSS feeds seem better for those notifications, but I have two feeds from github and they don't show the same things. Maybe we need to put together a tracking workflow document to supplement the git workflow document.<br>
<br>I'd also like to see bug fix commits go in and automatically notify the tracker with an @#666 or some such. I don't know if that sort of thing is possible with the github tracker or the github hooks.<br> <br></div>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span style="white-space:pre-wrap">     </span>3) Developer management of issues</div>
<div><br></div></div></blockquote><div><br>This is where Ralf comes in as I don't regard myself as that familiar with trac. The problem in choosing a new system is that one needs to actually use it for some serious work to properly evaluate it. But we don't have the time to do that, so we ask. And then everyone has their own favorite, perhaps because it is the only one they have used. What impressed me was that Ralf seems to have actually used several different systems.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>Now, it is also true that these three things don't have to all intersect.   It is very possible to have different systems manage different parts.    What I find less than optimal these days is having github as the web-site for pull requests and discussions around them and a poorly-performing trac for issue tracking and milestone management and a few wiki pages. </div>
<div><br></div><div>Can we at least agree to have all the wiki pages and web-site managed by github?     For issue tracking,  I'm very anxious for your and Ralf's opinion because of the effort you have spent using Trac over the years.<br>
</div></div></blockquote><div><br>It makes sense to move the wiki and web site. I hardly ever look at the developer Wiki anyway and might be more tempted to do so if it were up on github. It would also be good if those things could be managed in one place. As is, the permissions for managing things are split up and it isn't always clear who has the magic key.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div>Another developer I asked at LLNL, just said "why don't you use bugzilla"?   </div>
<div class="im"><div><br></div></div></div></blockquote><div class="im"><br>The simplest solution would be to use github, the question is whether the convenience and possibility of future improvements outweigh the better functionality of a dedicated system. In making that decision I think Ralf's opinion should carry the most weight since my experience in using trac for releases and such is much more limited than his. It might also be good to check on the ability of the different systems to export the data in some sensible format in case we change our minds. I suppose worker time and money are also part of the equation. If it looks like the github solution is cheaper and easier to manage, that in itself could be a significant factor in the choice. And that also argues for making a pick pretty soon, there is no point in having folks spending a few more weeks just trying things out.<br>
<br>Of course, the main problem with trac, which a better system won't solve, is having the time to deal with the issues. Fedora uses bugzilla, and after a ticket has aged sufficiently they simply close it on principal even if it hasn't been officially closed. No doubt a lot of things do get fixed without anyone connecting it to a specific ticket. Maybe we need to have a collection of failing tests, not just tests for things that have been fixed. If I could hit a button and send the problem code into a failure repository, formatted for nose and with a number and back link, that would be great. Maybe not up there with a flying car but certainly a close second. Something like that could even be part of a continuous integration system.<br>
<br>Chuck</div></div>