[Gdal-dev] Infrastructure developments for GDAL

[Bart van den Eijnden (OSGIS)]

Hi Howard,

the organization I currently work for is also experimenting with Trac, 
and it looks very promising, especially the subversion integration.

I think there won't be any doubts with moving CVS to SVN.

Best regards,
Bart

Howard Butler wrote:

> 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
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>
>


-- 
Bart van den Eijnden
OSGIS, Open Source GIS
http://www.osgis.nl