[Gdal-dev] Infrastructure developments for GDAL

[Howard Butler]

All,

With our upcoming move to OSGeo, I have been investigating the use of 
three technologies to help streamline some aspects of GDAL 
development -- subversion, Trac <http://trac.edgewall.com>, and 
buildbot <http://buildbot.sourceforge.net>.

GDAL has historically used Bugzilla, CVS, and mailman as the main 
project-enabling technologies.  While I have no issues with mailman, 
I do have a couple with bugzilla and cvs.  First, they aren't linked. 
In one sense, bugs are a separate universe from the source code (our 
bugzilla even resides on a different machine in a different domain). 
Two, bugzilla doesn't provide good overviews of all of the bugs 
related to a release, or bugs related to a development milestone. 
Third, bugzilla is a bit imposing and foreboding for casual bug 
reporters.

My issues with CVS are mostly related to repository reconfiguration, 
refractoring, and branching/tagging -- all issues that subversion was 
designed from the ground up to alleviate.  The migration to 
subversion for my internal projects has been very successful, and 
I've yet to find too many developers wishing they had CVS again after 
working with subversion for a while...

Trac example for GDAL <http://gdal.hobu.net/trac.gdal/> <-- click 
"View Tickets" to see bugs imported from bugzilla and "Browse Source" 
to see the GDAL CVS tree imported into subversion.  Trac integrates 
wiki, source code browsing, and bug reporting into one entity.  It is 
also relatively straightforward to write your own plugins to Trac to 
do interesting things.

The other infrastructure component that I have been investigating is 
automated smoke testing.  GDAL is a large piece of software that is 
expected to run on many different platforms.  GDAL has a testing 
suite, and   it is very useful if that test suite is run frequently 
on many different platforms as development takes place.     Buildbot 
provides a few very nice features, but one of the most useful is the 
ability for folks to hook up their own build slaves to the build 
farm.  For example, the Python buildbot 
<http://www.python.org/dev/buildbot/all> is composed of machines that 
users have connected to the build farm themselves and covers a wide 
variety of platforms and configurations.

Buildbot example for GDAL <http://gdal.builds.hobu.net> <-- nightly 
(and on-demand) builds of GDAL for linux, windows, and osx.

These links are *not* authoritative, and in no way has GDAL yet moved 
to these technologies.  I expect the upcoming PSC to vote on and 
approve the use of these technologies officially through the RFC 
process.  I wanted to give people a preview of these technologies and 
ask what people think about them.  Do/will they fit GDAL's 
development process?

Howard