[Numpy-discussion] Issue Tracking

[Charles R Harris]

On Mon, Apr 30, 2012 at 10:14 PM, Travis Oliphant <travis at continuum.io>wrote:

>
>
>> 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.
>>
>>
> 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.
>
> Chuck
>
>
>
> 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.
>
> But the issue tracking problem really is dividable into separate work
> flows:
>  1) The submission of the issue (here things like ease-of-entry and
> attaching files is critical)
>

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).

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.


> 2) The dialogue around the issue (developer comments on it and any
> discussion that ensues)
>

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.

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.


> 3) Developer management of issues
>
>
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.

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.
>
> 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.
>

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.


>
> Another developer I asked at LLNL, just said "why don't you use bugzilla"?
>
>
>
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.

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.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120501/1bb97797/attachment.html>