The one at github can be easily disabled.
On Sat, Feb 26, 2011 at 6:15 PM, Benjamin Root <ben.root@...553...> wrote:
Github has been a wonderful tool for *developers*, but for
users of projects, I haven't seen the amount of sophistication and polish
that sourceforge has.I am personally fine with continuing to use sourceforge for the tracker (I
know I need to catch up on bugs there...). My main concern, though, is
having two active issue trackers -- one on sourceforge and one on github.
Yup. I hold on to the hope that, because it's so egregiously,
painfully broken and braindead and it stands out so badly in
comparison to the rest of github (which is brilliant), that it won't
be too long before this improves. Granted, we can't know what's on
their internal todo list, but those guys are obviously good and listen
to feedback (from what I've seen elsewhere on the site), and their bug
tracker has become something of a laughing stock, so I can only
imagine that they're actually working on it.
In the meantime, Min recently pointed out this interesting alternative:
http://githubissues.heroku.com/#darrendale/mpl-issues
You can point it to any repository you want, and it makes interacting
with the issue list far, far saner than via github itself.
We're using now that interface ourselves for IPython:
http://githubissues.heroku.com/#ipython/ipython
and I have to say that I like it quite a bit. For those on OSX, this
can even be installed to run locally, with the feel of a native app
(it's still a webkit app, but it launches like a local app).
Something to keep in mind as you make the decision...
In the end, in IPython we decided to move to github in order to
benefit from the close integration between pull requests, bugs and
commits. Pull requests automatically create an issue, one can close
bugs automatically from the commit message, etc. I figured these
things would be nice to have for an everyday workflow, and that
eventually github itself would improve its native bug system.
Cheers,
f
On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale <dsdale24@...149...> wrote:
I agree that the github interface is not great. The github devs seem
to know that everybody complains about it.
I agree that the github interface is not great. The github devs seem
to know that everybody complains about it.Yup. I hold on to the hope that, because it's so egregiously,
painfully broken and braindead and it stands out so badly in
comparison to the rest of github (which is brilliant), that it won't
be too long before this improves. Granted, we can't know what's on
their internal todo list, but those guys are obviously good and listen
to feedback (from what I've seen elsewhere on the site), and their bug
tracker has become something of a laughing stock, so I can only
imagine that they're actually working on it.In the meantime, Min recently pointed out this interesting alternative:
It is impressive, and improves some aspects, but I don't see that it makes the github tracker usable for new tickets. I don't see any facility for attaching a file--is this correct? We really want users with problems and suggestions to attach minimal example files, patches, whatever--as downloadable files, not pasted into the comment box.
My inclination would be to keep using the SF tracker exclusively until the github tracker improves substantially, and then switch.
Eric
On 02/26/2011 01:44 PM, Fernando Perez wrote:
On Sat, Feb 26, 2011 at 3:24 PM, Darren Dale<dsdale24@...149...> wrote:
You can point it to any repository you want, and it makes interacting
with the issue list far, far saner than via github itself.We're using now that interface ourselves for IPython:
http://githubissues.heroku.com/#ipython/ipython
and I have to say that I like it quite a bit. For those on OSX, this
can even be installed to run locally, with the feel of a native app
(it's still a webkit app, but it launches like a local app).Something to keep in mind as you make the decision...
In the end, in IPython we decided to move to github in order to
benefit from the close integration between pull requests, bugs and
commits. Pull requests automatically create an issue, one can close
bugs automatically from the commit message, etc. I figured these
things would be nice to have for an everyday workflow, and that
eventually github itself would improve its native bug system.Cheers,
f
------------------------------------------------------------------------------
Free Software Download: Index, Search& Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
It is impressive, and improves some aspects, but I don't see that it
makes the github tracker usable for new tickets. I don't see any
facility for attaching a file--is this correct? We really want users
with problems and suggestions to attach minimal example files, patches,
whatever--as downloadable files, not pasted into the comment box.
No, that's a current limitation of the github tracker. As a poor
man's attachment system, github does have the gist system:
that makes it easy to drop any file (small or large) and have it
permanently stored on GH with a stable url.
But I agree that the tracker should have proper file attachments
built-in, using gist is just a workaround, and one most people won't
necessarily know about gist or think of it as a way to attach files to
the tracker.
My inclination would be to keep using the SF tracker exclusively until
the github tracker improves substantially, and then switch.
Since we did switch for ipython, here's me keeping my fingers
painfully crossed for that day to come earlier rather than later...
Cheers,
f
On Sat, Feb 26, 2011 at 6:14 PM, Eric Firing <efiring@...229...> wrote:
Darren Dale <dsdale24@...149...> writes:
The submitter info is lost?
And when it was originally submitted?No, I can improve it so this information is included.
That's clearly in the xml file, except that I don't know if we can map
sourceforge userids to email addresses - that sounds like something that
spammers would want to do.
One thing that I think is missing in the xml file are the attachment
contents. There are filenames and some kind of ids that presumably can
be used to get the files via the sf bug pages, but this information only
occurs in the artifact_history subsection. To get the correct files
you'll have to first parse this to figure out that file 396374 was added
but then deleted and then file 396688 was added:
<field name="artifact_history">
<history>
<field name="field_name">File Added</field>
<field name="old_value">396688: set_verts_cleanup_2.patch</field>
<field name="entrydate">1293000689</field>
<field name="mod_by">notmuchtotell</field>
</history>
<history>
<field name="field_name">File Deleted</field>
<field name="old_value">396374: </field>
<field name="entrydate">1293000467</field>
<field name="mod_by">notmuchtotell</field>
</history>
<history>
<field name="field_name">File Added</field>
<field name="old_value">396374: set_verts_cleanup.patch</field>
<field name="entrydate">1292605835</field>
<field name="mod_by">notmuchtotell</field>
</history>
I agree that the github interface is not great. The github devs seem
to know that everybody complains about it.There are some good things about it though. Labels, the ability to
link between an issue and the commits that resolve it, the ability for
people to provide feedback on what issues are important to them.
Does anyone have experience with other trackers? bugs.python.org seems
to be using Roundup - any experiences with that?
On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <efiring@...229...> wrote:
On 02/26/2011 10:54 AM, Darren Dale wrote:
--
Jouni K. Sepp�nen
Darren Dale <dsdale24@...149...> writes:
The submitter info is lost?
And when it was originally submitted?No, I can improve it so this information is included.
That's clearly in the xml file, except that I don't know if we can map
sourceforge userids to email addresses - that sounds like something that
spammers would want to do.
I was thinking to just use the SourceForge IDs.
One thing that I think is missing in the xml file are the attachment
contents. There are filenames and some kind of ids that presumably can
be used to get the files via the sf bug pages, but this information only
occurs in the artifact_history subsection. To get the correct files
you'll have to first parse this to figure out that file 396374 was added
but then deleted and then file 396688 was added
That's a good idea. But given the limitations of attaching files to
issues at github, I thought it would be better to instead provide
enough context in the github issue (SourceForge messages and history)
so that if such files are needed, they could be retrieved from
SourceForge.
My thinking on issue tracking is similar to Fernando's. Github issues
integration with some of the other features of the site is really
nice, and makes the issue tracker much more a part of the development
process than was the case at sourceforge. But its a different
paradigm: patches are submitted as pull requests rather than
attachments in the issue tracker.
Here is another big change difference: tickets can be created at
sourceforge without a sourceforge account (hence the spam). At github,
you have to have an account to file a ticket.
I agree that the github interface is not great. The github devs seem
to know that everybody complains about it.There are some good things about it though. Labels, the ability to
link between an issue and the commits that resolve it, the ability for
people to provide feedback on what issues are important to them.Does anyone have experience with other trackers? bugs.python.org seems
to be using Roundup - any experiences with that?
I have not worked with Roundup. I have a little experience with Trac
(meh), and with Launchpad (good integration with project management
features, which are lacking at github.) What I was thinking to achieve
by testing migration of the issues to github was not simply to get
away from sourceforge, but to benefit from the integration of
services. If we are not convinced that github issues provides
everything we need, I think we should provide feedback to the github
devs and stick with sourceforge for the time being.
Darren
On Sun, Feb 27, 2011 at 7:46 AM, Jouni K. Seppänen <jks@...278...> wrote:
On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <efiring@...229...> wrote:
On 02/26/2011 10:54 AM, Darren Dale wrote:
Here is a copy of a message I just sent to support@...936... If you
have other specific concerns, please let me know, and I will pass them
along if I hear back from someone at github.:
Hello,
Thank you for all your great work on github.
I am one of the developers of the matplotlib project
(matplotlib.github.com). We recently converted our svn repositories to
git, and started hosting them at github. This weekend I worked on
testing migrating the issues from the sourceforge tracker (see
https://github.com/darrendale/mpl-issues), but we have some concerns
about the usability of the github issue tracker:
* Our project produces graphical output, so the ability to attach
files (like images and test scripts) to an issue is of critical
importance to our project.
* We would miss the ability to file tickets through the browser
without signing in to github.
* Having to repeatedly request "more" to see all the tickets is rather painful
* We would miss the ability to assign a ticket to a developer.
Creating a label for a developer is not seen to be enough. It would be
nice if we could actually assign a developer to an issue, and from
then on only the developer would receive emails concerning activity on
the issue, unless others requested notifications.
* It would be nice if people could register/unregister to receive
notifications when there is activity on a specific issue that affects
them.
* It would be nice to be able to mark issues as pending after they are
committed, and mark them as closed when publicly released, along with
the release version(s) which addressed the problem (this latter
feature would be brilliant if github had project management features)
* It would be nice to mark an issue as a duplicate, automatically
linking to the appropriate issue and registering the reporter for
updates on the open issue
I have made the case to the other devs that the benefits of github
issues integration with the rest of the site is compelling, but at the
end of the day, some of these features are too important to us to
migrate to github issues at this time.
Concerning the websites, in general I like the gh-pages and
myproject.github.com solutions. However, the matplotlib documentation
is generated from RestructuredText using Sphinx. The resulting html is
about 80 MB, and has a lot of graphics and examples. We would rather
not track changes to this generated content, since we already track
changes to the (much smaller) source: it takes up additional space and
takes a long time to upload to the server.
Finally, I was hoping that you might consider adding some project
management features to github. About a year ago, I migrated a project
(github.com/python-quantities) from Launchpad. I like github much
better, but miss some of Launchpad's project management features. For
instance, it would be nice if we could specify and schedule an
upcoming release at github (which could be used to integrate with
pending issue closures), and then once we create the corresponding tag
in git, github creates a new directory in an official releases
downloads area (perhaps along with .zip and .tgz files). Also, the
release graph at a projects main page at Launchpad was nice.
I hope this doesn't seem too critical, I just wanted to give some
constructive feedback. Thank you again for all you've done!
Best regards,
Darren Dale
On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale <dsdale24@...149...> wrote:
If we are not convinced that github issues provides
everything we need, I think we should provide feedback to the github
devs and stick with sourceforge for the time being.
Having said that, depending on how the github devs respond, we might
want to give lighthouse (lighthouseapp.com) a look. It claims to
integrate with github, supports attachments, integrates with email,
would support separate trackers for the various matplotlib repos, and
it is apparently free for open-source projects:
http://matplotlib.lighthouseapp.com/projects/70830-matplotlib/overview
.
If you are interested in playing around with lighthouse and want
elevated privileges, send me (off list) the email address you used to
sign up at lighthouse. If it looks promising, we could see how well it
integrates with github.
On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale <dsdale24@...149...> wrote:
If we are not convinced that github issues provides
everything we need, I think we should provide feedback to the github
devs and stick with sourceforge for the time being.
Here is the exchange I had with one of github's support staff:
GH: Thank you very much for your feedback. We already work on improving issues.
DD: Thank you for your reply. Is it ok if I relay this information to
the other developers on my project?
GH: Yes, but let me just say that we never have an ETA and also I
can't confirm that you'll be completely satisfied with our
improvements.
On Sun, Feb 27, 2011 at 9:45 AM, Darren Dale <dsdale24@...149...> wrote:
On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale <dsdale24@...149...> wrote:
If we are not convinced that github issues provides
everything we need, I think we should provide feedback to the github
devs and stick with sourceforge for the time being.Here is a copy of a message I just sent to support@...936... If you
have other specific concerns, please let me know, and I will pass them
along if I hear back from someone at github.