[Numpy-discussion] Issue Tracking

Charles R Harris charlesr.harris at gmail.com
Tue May 1 02:24:17 EDT 2012

On Tue, May 1, 2012 at 12:16 AM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

> 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.
I'll add that tickets don't get looked at as often as they should and that
is an important consideration. Having them up on github might help in that

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

More information about the NumPy-Discussion mailing list