On Sun, Feb 27, 2011 at 7:46 AM, Jouni K. Seppänen <j...@iki.fi> wrote: > Darren Dale <dsdal...@gmail.com> writes: > >> On Sat, Feb 26, 2011 at 5:58 PM, Eric Firing <efir...@hawaii.edu> 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 ------------------------------------------------------------------------------ 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
