[postgis-devel] SVN Development Branch

[Mateusz Loskot]

Jorge Arévalo wrote:
> Hi guys,
> 
> I'd like to suggest a svn development branch, to share the
> development issues but avoid untested code on official svn. Is it
> possible? I have my own svn hosting, if OSGeo can't provide us one.
> 
> What do you think?

I'm not sure it is necessary.
We are still in early pre-release development stage.
We have the code versioned, so it's always possible to go back.
Maintaining separate branch is a hassle, time consuming and error prone
process. IMHO, it would make sense only after we have released stable
version.

I believe we can assure degree of quality with obeying basic rules
and development cycle process, most of them are easily executable,
(semi-)automatically:

1. If you add new C API function, always add test case for it
   in test/core

2. If you add new SQL function, always add a test case for it.
   in test/regression

3. Always do full build of WKT Raster before commit (with
   new tests included)

4. Always run all WKT Raster unit tests before commit (with new
   tests included)

5. Do not commit anything if any of the two occurs:
   a) WKT Raster build failed b) WKT Raster tests failed

6. Try to do full rebuild and full tests run of all related components:
   GEOS + PostGIS + WKT Raster

7. Frequently check if WKT Raster build is "green" in the very our :-)
   Hudson bay http://office.refractions.net:1500/view/WKTRaster/

8. Don't worry if something got broken after a commit. A broken code
   is a daily bread and errors are valuable. Just don't let buggy
   commits to accumulate, but fix as soon as first error is spotted.

Adding new test cases are the only time consuming element, but even a
very simple test is worth (i.e. test/regress/rt_box2d.sql)

IMHO, these simple rules are quite enough to fulfil continuous
integration principle. The 8 points is nothing extra-ordinary,
it's just a common practice.

p.s. CC to postgis-devel

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org