[postgis-devel] SVN Development Branch

[Jorge Arévalo]

On Mon, Feb 8, 2010 at 3:26 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca> wrote:
> I would tend to agree with Mateuzs on that. Branches are a nightmare to maintain...
>
Ok.


> I would suggest you commit the test code (once it is somewhat working), but comment it out. We can activate it if we want to build it and we can delete it when we know what we want to keep.
>
Ok.


> There is a "Expectation from developpers" in the planning page. I would suggest to create a kind of "Advices to developers" where we could keep Mateusz 8 rules as a reminder and a reference.
>

Sure thing. I'll create it.

Best regards,
Jorge


> Pierre
>
>>> 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
>