<br><br><div class="gmail_quote">On Wed, May 2, 2012 at 11:25 PM, Wes McKinney <span dir="ltr"><<a href="mailto:wesmckinn@gmail.com" target="_blank">wesmckinn@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div><div>On Wed, May 2, 2012 at 9:48 AM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, May 1, 2012 at 11:47 PM, Ralf Gommers <<a href="mailto:ralf.gommers@googlemail.com" target="_blank">ralf.gommers@googlemail.com</a>><br>
> wrote:<br>
>><br>
>><br>
>><br>
>> On Wed, May 2, 2012 at 1:48 AM, Pauli Virtanen <<a href="mailto:pav@iki.fi" target="_blank">pav@iki.fi</a>> wrote:<br>
>>><br>
>>> 01.05.2012 21:34, Ralf Gommers kirjoitti:<br>
>>> [clip]<br>
>>> > At this point it's probably good to look again at the problems we want<br>
>>> > to solve:<br>
>>> > 1. responsive user interface (must absolutely have)<br>
>>><br>
>>> Now that it comes too late: with some luck, I've possibly hit on what<br>
>>> was ailing the Tracs (max_diff_bytes configured too large). Let's see if<br>
>>> things work better from now on...<br>
>><br>
>><br>
>> That's amazing - not only does it not give errors anymore, it's also an<br>
>> order of magnitude faster.<br>
>><br>
><br>
> So maybe we could just stick with trac. Performance was really the sticking<br>
> point.<br>
><br>
> Chuck<br>
><br>
><br>
</div></div><div>> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
><br>
<br>
</div>FWIW I'm pretty strongly in favor of GHI for NumPy/SciPy (I am going<br>
to get involved in NumPy dev eventually, promise). While warty in some<br>
of the places already mentioned, I have found it to be very<br>
low-friction and low-annoyance in my own dev process (nearing 1000<br>
issues closed in the last year in pandas). But there are fewer cooks<br>
in the kitchen with pandas so perhaps this experience wouldn't be<br>
identical with NumPy. The biggest benefit I've seen is community<br>
involvement that you really wouldn't see if I were using a Trac or<br>
something else hosted elsewhere. Users are on GitHub and it for some<br>
reason gives people a feeling of engagement in the open source process<br>
that I don't see anywhere else.</blockquote><div><br>Feels like it's time to make a decision on this. <br><br>I see no blocking objections against Github, so perhaps we should give it a go. The attachment issue for data files can be solved by relocating those to a server we still administer. Trac is currently annoying me also, because I need to change the milestone of ~50 tickets and have no good way of doing it. So nothing's perfect. Github's hosting service, possibly more user involvement and centralizing all our tools there may be enough to outweigh the limitations of GHI.<br>
<br>Proposal: move NumPy tickets to Github.<br><br>Ralf<br><br></div></div>