[Numpy-discussion] Migrating issues to GitHub
Travis Oliphant
Benjamin Root
The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves.
Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration.
Cheers!
Ben Root
Pauli Virtanen
> How to people feel about moving the issue tracking for NumPy to Github?
> It looks like they have improved their issue tracking quite a bit and
> the workflow and integration with commits looks quite good from what I
> can see.
The lack of attachments is the main problem with this transition. It's
not so seldom that numerical input data or scripts demonstrating an
issue come useful. This is probably less of an issue for Numpy than for
Scipy, though.
Pauli
_______________________________________________
NumPy-Discussion mailing list
NumPy-Di...@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Travis Oliphant
Ben Root _______________________________________________
Charles R Harris
This is good feedback.It looks like there are 2 concerns:1) no way to add attachments --- it would seem that gists and indeed other github repos solves that problem.2) You must be an admin to label an issue (i.e. set it as a bug, enhancement, or so forth).This second concern seems more of a problem. Perhaps this is something that can be brought up with the github developers directly. Not separating issue permissions from code permissions seems rather unfortunate, and creates work for all admins.On the other hand, it might force having an admin who is paying regular attention to the issues which is not necessarily a bad thing.So, despite the drawback, it seems that having issues on Trac and having code-conversations on those issues happening separately from the pull-request conversations is even less optimal.
It does present a problem for migrating current trac as a number of the tickets have attachments and we don't want to lose them.
On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote:Ben Root _______________________________________________
On Saturday, February 11, 2012, Travis Oliphant <tra...@continuum.io> wrote:
> How to people feel about moving the issue tracking for NumPy to Github? It looks like they have improved their issue tracking quite a bit and the workflow and integration with commits looks quite good from what I can see.
> Here is one tool I saw that might help in the migration: https://github.com/trustmaster/trac2github
> Are there others?
> -Travis
>
This is probably less of an issue for numpy, but our biggest complaint about the github tracker for matplotlib is the inability for users to add attachments.
The second complaint is that it is awkward to assign priorities (has to be done via labels). Particularly, users can not apply labels themselves.
Mind you, neither of these complaints were enough to completely preclude mpl from migrating, but it should be taken into consideration.
Cheers!
Chuck
Fernando Perez
> The lack of attachments is the main problem with this transition. It's
> not so seldom that numerical input data or scripts demonstrating an
> issue come useful. This is probably less of an issue for Numpy than for
> Scipy, though.
We've taken to using gist for scripts/data and free image hosting
sites for screenshots, using
<img src="http://.... /img>
to show the screenshot in the bug report when relevant. Not always
ideal, but it does get the job done, and actually with gist, it's kind
of nice that the 'attachment' can evolve with version control too.
The lack of real priorities *is* a hassle, at least for me. I
understand the rationale behind a very simple UI and unstructured
labels, but priority is such a central concept to bug tracking that
its absence is a shortcoming, pure and simple.
In summary, in IPython we've been using the gh tracker for almost 2
years, and since the updates to issues 2.0, with milestones and
individual assignee fields, they are quite serviceable. In the
balance, I feel the benefits of tight integration with the rest of the
site outweigh the limitations, though I'll be very happy if those
limitations are removed in future upgrades to the site.
Cheers,
f
Jason Grout
Are there any good github trac plugins? For example:
http://davglass.lighthouseapp.com/projects/21212/home
http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe
useful)
Thanks,
Jason
Travis Oliphant
Pauli Virtanen
[clip]
> Are there any good github trac plugins? For example:
>
> http://davglass.lighthouseapp.com/projects/21212/home
>
> http://trac-hacks.org/wiki/GitPlugin (git, not github, but still maybe
> useful)
The Numpy & Scipy Trac is currently running on this:
https://github.com/pv/githubsimple-trac
Eric Firing
> This is good feedback.
>
> It looks like there are 2 concerns:
>
> 1) no way to add attachments --- it would seem that gists and indeed
> other github repos solves that problem.
Not really, in practice. Yes one can use these mechanisms, but they are
much clunkier and more obscure than simply being able to attach files
via an immediate interface. So the barrier to actual use is high.
> 2) You must be an admin to label an issue (i.e. set it as a bug,
> enhancement, or so forth).
A third problem is that the entire style of presentation is poorly
designed from a use standpoint, in comparison to the sourceforge tracker
which mpl used previously. The github tracker appears to have been
designed by a graphics person, not a software maintainer. The
information density in the issue list is very low; it is impossible to
scan a large number of issues at once; there doesn't seem to be any
useful sorting and selection mechanism.
>
> This second concern seems more of a problem. Perhaps this is something
> that can be brought up with the github developers directly. Not
> separating issue permissions from code permissions seems rather
> unfortunate, and creates work for all admins.
This doesn't seem so bad to me, at least compared to the *really* bad
aspects.
>
> On the other hand, it might force having an admin who is paying regular
> attention to the issues which is not necessarily a bad thing.
>
> So, despite the drawback, it seems that having issues on Trac and having
> code-conversations on those issues happening separately from the
> pull-request conversations is even less optimal.
The one good thing about the github tracker is its integration with the
code. Otherwise it is still just plain bad, and will remain so until it
is given an information-dense tabular interface, with things like
initiation date, last update, category, priority, etc. Down with
whitespace and icons! We need information!
Eric
>
> -Travis
>
>
>
> On Feb 11, 2012, at 2:06 PM, Benjamin Root wrote:
>
>>
>>
>> On Saturday, February 11, 2012, Travis Oliphant <tra...@continuum.io
>> <mailto:tra...@continuum.io>> wrote:
>> > How to people feel about moving the issue tracking for NumPy to
>> Github? It looks like they have improved their issue tracking quite a
>> bit and the workflow and integration with commits looks quite good
>> from what I can see.
>> > Here is one tool I saw that might help in the migration:
>> https://github.com/trustmaster/trac2github
>> > Are there others?
>> > -Travis
>> >
>>
>> This is probably less of an issue for numpy, but our biggest complaint
>> about the github tracker for matplotlib is the inability for users to
>> add attachments.
>>
>> The second complaint is that it is awkward to assign priorities (has
>> to be done via labels). Particularly, users can not apply labels
>> themselves.
>>
>> Mind you, neither of these complaints were enough to completely
>> preclude mpl from migrating, but it should be taken into consideration.
>>
>> Cheers!
>> Ben Root _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Di...@scipy.org <mailto:NumPy-Di...@scipy.org>
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
Jason Grout
> A third problem is that the entire style of presentation is poorly
> designed from a use standpoint, in comparison to the sourceforge tracker
> which mpl used previously. The github tracker appears to have been
> designed by a graphics person, not a software maintainer. The
> information density in the issue list is very low; it is impossible to
> scan a large number of issues at once; there doesn't seem to be any
> useful sorting and selection mechanism.
I agree. Also, another thing that is really frustrating is that the
issue number does not appear in the listing. So when you are trying to
refer to another issue, and try finding it by scanning the list, you
have to mouse over the title and extract the information mentally from
the url.
Google code issues are much, much better in these regards.
Jason
Mark Wiebe
On 02/11/2012 10:44 AM, Travis Oliphant wrote:<snip>
> 2) You must be an admin to label an issue (i.e. set it as a bug,> enhancement, or so forth).A third problem is that the entire style of presentation is poorly
designed from a use standpoint, in comparison to the sourceforge tracker
which mpl used previously. The github tracker appears to have been
designed by a graphics person, not a software maintainer. The
information density in the issue list is very low; it is impossible to
scan a large number of issues at once; there doesn't seem to be any
useful sorting and selection mechanism.
David Cournapeau
> On Sat, Feb 11, 2012 at 3:12 PM, Eric Firing <efi...@hawaii.edu> wrote:
>>
>> On 02/11/2012 10:44 AM, Travis Oliphant wrote:<snip>
>
>
>>
>> > 2) You must be an admin to label an issue (i.e. set it as a bug,
>> > enhancement, or so forth).
>>
>> A third problem is that the entire style of presentation is poorly
>> designed from a use standpoint, in comparison to the sourceforge tracker
>> which mpl used previously. The github tracker appears to have been
>> designed by a graphics person, not a software maintainer. The
>> information density in the issue list is very low; it is impossible to
>> scan a large number of issues at once; there doesn't seem to be any
>> useful sorting and selection mechanism.
>
>
> The lack of a tabular way to mass-edit bugs is one of my biggest problems
> with the current trac. One thing that ideally we could do regularly is to
> rapidly triage 100s of bugs. Currently trac requires you to go through them
> one by one, like harvesting wheat with a scythe instead of a combine. Users
> who are mentioned in a lot of tickets also get spammed by a large number of
> message, instead of getting a single summary update of all the triaging that
> was done.
>
> Does the github bug tracker have a good story about mass bug-updating?
Github is better than trac on that issue: updating the milestone for
many bugs at once is simple. You don't have priorities, etc…, though.
The Rest API also enables in principle to write tools to automate the
repetitive tasks.
David
Thouis (Ray) Jones
> On Sat, Feb 11, 2012 at 12:36 PM, Pauli Virtanen <p...@iki.fi> wrote:
>> The lack of attachments is the main problem with this transition. It's
>> not so seldom that numerical input data or scripts demonstrating an
>> issue come useful. This is probably less of an issue for Numpy than for
>> Scipy, though.
>
> We've taken to using gist for scripts/data and free image hosting
> sites for screenshots, using
>
> <img src="http://.... /img>
CellProfiler recently transitioned to Github issues from an internal
Jira server. Since most of our bug reports require some sort of
attachment to be useful, we put up a page at cellprofiler.org/issues
that uses Github's authentication API to file bugs with attachments.
The bug report itself gets added to the github issues, the attachment
gets stored on our server, and links to the latter appear in the
former.
bug page: http://cellprofiler.org/issues/
example issue: https://github.com/CellProfiler/CellProfiler/issues/260
It was pretty simple to put together (a few hours by one developer).
The need for a github account keeps it from being spammed. If that's
too much of a bar, I expect it could have a branch-cut in behavior:
witha github account, the report goes straight into the Github
issues, otherwise, it gets queued for review and mail sent to some
(hopefully low-traffic) list.
Ray Jones
Ralf Gommers
On Sat, Feb 11, 2012 at 21:54, Fernando Perez <fpere...@gmail.com> wrote:CellProfiler recently transitioned to Github issues from an internal
> On Sat, Feb 11, 2012 at 12:36 PM, Pauli Virtanen <p...@iki.fi> wrote:
>> The lack of attachments is the main problem with this transition. It's
>> not so seldom that numerical input data or scripts demonstrating an
>> issue come useful. This is probably less of an issue for Numpy than for
>> Scipy, though.
>
> We've taken to using gist for scripts/data and free image hosting
> sites for screenshots, using
>
> <img src="http://.... /img>
Jira server.
In another thread Jira was proposed as an alternative to Trac. Can you point out some of its strengths and weaknesses, and tell us why you decided to move away from it?
Thanks,
Ralf
Thouis (Ray) Jones
> In another thread Jira was proposed as an alternative to Trac. Can you point
> out some of its strengths and weaknesses, and tell us why you decided to
> move away from it?
The two primary reasons were that our Jira server was behind a
firewall and we wanted to open it up, and the integration with github,
where we were moving our source.
My own impression is that Jira is much more complicated. It was nice
that it was integrated with Fisheye and some reporting tools, but I
found them so complicated to deal with that I usually didn't go beyond
"show me my bugs", some bulk bug editing, and adding users to
projects. As a group, we had difficulties keeping track of how we
were indicating priority and planned work, even with wiki pages to
tell us what we intended the different labels to mean. Jira's
integration with other tools (Fisheye, Crucible) was useful in some
ways, but in no way critical. There were all kinds of reports (LOC,
bug count, etc.) that one could get from these, but nothing that
couldn't be created with pylab and a free hour or two.
I like github's issues for their simplicity and the http-based API.
We miss having direct attachements, but we have a workaround. It
would be nice if the github issues page were more customizable, but
with the API, a motivated group could create whatever frontend they
wanted.
Github's issues remind me of python, Jira reminded me of Java. I
guess Jira would be more suited to a large developments effort with
multiple groups of programmers, which we were not. Moving bugs from
Jira to github wasn't too bad (we dropped most of the metadata, except
for our current/next/future label for which release fixes would go
into). I think it would be easier to move from github to Jira,
primarily because github has fewer possible bits of metadata on each
bug.
As I said, I avoided using Jira for anything really complicated, so
perhaps I just needed to spend more time with it. My opinion should
probably not be given undue weight.
Ralf Gommers
On Thu, Feb 16, 2012 at 19:25, Ralf Gommers <ralf.g...@googlemail.com> wrote:
> In another thread Jira was proposed as an alternative to Trac. Can you point
> out some of its strengths and weaknesses, and tell us why you decided to
> move away from it?
....
Jira reminded me of Java.
OK, you convinced me:)
Ralf
Wes McKinney
> NumPy-Discussion mailing list
> NumPy-Di...@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
Having just created a NumPy ticket
(http://projects.scipy.org/numpy/ticket/2065) I feel pretty strongly
about moving the issue tracker to GitHub--the lack of attachments is
easy to work around. I think it will help a lot for building more
community engagement with the development process. My experience using
it with pandas has been very positive-- I have churned through around
700 issues over the last 12 months and I've never felt like it's
gotten in my way (except for the occasional CSS/JS bugs in the web
UI).
- Wes