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