gEDA development

There has been a lot of talk recently about how, as a community, gEDA (including PCB), has failed to make best use of its community contributions. The standard excuses have all been made for why we have not been better at integrating patches:

• Developer bandwidth
• Unfamiliarity with the code, so I can't review it
• Submitted code quality not high enough
• Sumbitted code not confirmat to our (non-existant) formal coding style.
• "I hate SourceForge" - Ok, that one was just me!

All of the above are true for various cases, but as a community we need to do better. As such, I've been trying to devote some spare cycles to doing what I can to improve the situation.

For me, the SourceForge trackers are a real productivity drain when reviewing code. I've been doing some of the groundwork to trial Canonical's Launchpad as an alternative. This has meant exporting a dump of data from SourceForge, and applying various scripts and manual editing to convert this data into a format Launchpad admins can import into their database.

There have been a few snags along the way, mostly just requiring customisations to the python script which converts the SourceForge export into a Launchpad import format. I have added custom code for mapping release targets assigned to our bugs, cleaning up various auto-generated headers from comments, and tagging the imported bugs to specify which of the SourceForge trackers they originated from.

The results look promising, and in a few days I hope to be able to show people an editable demonstration of the import (for PCB), on the Launchpad staging server.

An example of an imported feature request