On Sun, Feb 27, 2011 at 7:46 AM, Jouni K. Seppänen <jk...@ik...> wrote: > Darren Dale <dsd...@gm...> writes: > >> On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <ef...@ha...> wrote: >>> On 02/26/2011 10:54 AM, Darren Dale wrote: >>> >>> 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 8:32 AM, Darren Dale <dsd...@gm...> 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 <dsd...@gm...> 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 su...@gi.... 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 9:45 AM, Darren Dale <dsd...@gm...> wrote: > On Sun, Feb 27, 2011 at 8:32 AM, Darren Dale <dsd...@gm...> 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 su...@gi.... If you > have other specific concerns, please let me know, and I will pass them > along if I hear back from someone at github. 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.