Changes between Version 65 and Version 66 of WKTRaster/PlanningAndFunding

Timestamp:

02/12/10 02:53:40 (15 years ago)

Author:

jorgearevalo

Comment:

Advices to developers, thanks to Mateusz Loskot.

WKTRaster/PlanningAndFunding

@@ -33 +33 @@
  * Contribute to the specifications in order to agree and to keep track of what's done. Specifications of the intented development should be described in the Specifications page and submited to the postgis-devel mailing list  for comments before starting development. Ask [http://www.cef-cfr.ca/index.php?n=Membres.PierreRacine Pierre Racine] to get write access to the specification page.
  * Contribute to the Documentation as much as they can to make sure we produce a coherent and a professional open source product.
+
+'''Advices to developers -''' We can assure degree of quality with obeying basic rules and development cycle process, most of them are easily executable:
+
+ 1. If you add new C API function, always add test case for it in test/core.
+ 1. If you add new SQL function, always add test case for it in test/regression.
+ 1. Always do full build of WKT Raster before commit (with new tests included).
+ 1. Always run all WKT Raster unit tests before commit (with new tests included).
+ 1. Do not commit anything if any of the two occurs: a) WKT Raster build failed b) WKT Raster tests failed.
+ 1. Try to do full rebuild and full tests run of all related components: GEOS + PostGIS + WKT Raster.
+ 1. Frequently check if WKT Raster build is "green" in the very our :-) Hudson bay http://office.refractions.net:1500/view/WKTRaster/
+ 1. 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.
+ 1. 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)
+
 
 '''Tasks -''' Tasks are arranged into coherent groups: Similar functions together and dependencies first.