Index: /branches/PublicaMundi_David-devel/docs/contribute/contributors.rst =================================================================== --- /branches/PublicaMundi_David-devel/docs/contribute/contributors.rst (revision 699) +++ /branches/PublicaMundi_David-devel/docs/contribute/contributors.rst (revision 700) @@ -13,4 +13,30 @@ * Venkatesh RAGHAVAN (aka venka) +ZOO Project Steering Comitee +---------------------------- + +The ZOO Project Steering Comitee is responsible to manage the project +which is maintained, improved, and supported by a small but growing +developer community. The PSC is composed of the following people (by +alphabetical order): + + * Nicolas BOZON (`GeoLabs SARL `_), FR + * Maria Antonia BROVELLI (`Politecnico di Milano + `_), IT + * Massimiliano CANNATA (`SUPSI `_), CH + * Gérald FENOY (`GeoLabs `_), FR **(Chair)** + * Hirofumi HAYASHI (`AppTech `_), JP + * Daniel KASTL (`Georepublic `_), DE + * Jeff McKENNA (`Gateway Geomatics + `_), CA + * Markus NETELER (`Fondazione Edmund Mach + `_), IT + * Venkatesh RAGHAVAN (`Osaka City University + `_), JP + * Angelos TZOTSOS (`National Technical University of Athens + `_), GR + + + ZOO-Project Commiters --------------------- @@ -24,5 +50,5 @@ * Luca DELUCCHI (aka lucadelu) * René-Luc D'HONT (aka reluc) - * Gérald FENOY (aka djay) + * Gérald FENOY (aka djay) **Admin** * Knut LANDMARK (aka knut) * Jeff MCKENNA (aka jmckenna) @@ -39,5 +65,4 @@ * Thomas GRATIER - * Hirofumi HAYASHI * Guillaume SUEUR * Daisuke YOSHIDA Index: /branches/PublicaMundi_David-devel/docs/contribute/release.rst =================================================================== --- /branches/PublicaMundi_David-devel/docs/contribute/release.rst (revision 699) +++ /branches/PublicaMundi_David-devel/docs/contribute/release.rst (revision 700) @@ -1,84 +1,62 @@ - .. _contribute_release: +.. _contribute_release: -Release procedure -================================ +Release Procedure +================= -General rules ------------------- + * Any ZOO-Project commiter can ask for a release by asking the ZOO-Project PSC and pointing a release manager. This last will then vote for accepting both the manager and the release procedure to happen. + * If not already created, create a wiki page (like this `this one `_ using this scheme: Release/M.m.r/Notes), summarizing changes from the previous release (extracted from the `revision log `_). + * That file should include new features, changed features, and deprecated features if any. Changes to the official documentation should be specifically noted along with other items that will cause breaking changes during upgrades. + * Read the documentation and remove outdated parts. + * Create release candidate as .zip and .tar.bz2 then add them on this `page `_ (by editing this `wiki page `_) + * Cut a release candidate once you think that everything is in order. Announce the release candidate for review for at least 1 week. In this period of time, it is also appropriate for you to deploy in production since you are asserting that it is stable and (significant) bug free. Publish a specific revision with this. + * If significant bugs are reported, fix and cut a new release candidate. If no major bugs, then announce that the release candidate has officially been promoted to the official release (if you want, you can do this with a motion and support of the PSC). + * Ensure that release exactly matches something in SVN. Tag and branch appropriately. + * Update documentation as needed. + * Announce on various email list and other locations (news_item@osgeo.org, SlashGeo, etc) -The ZOO-Project release procedure is commonly defined by the following rules: - - * Any ZOO-Project commiter can ask for a release by asking the ZOO-Project PSC and pointing a release manager. This last will then vote for accepting both the manager and the release procedure to happen. - * It is first needed to create a wiki page summarizing the changes from the previous release (extracted from the revision log file called - `HISTORY `__ ). - * That wiki page should include new features, changed features, and - deprecated features if any. Changes to the official documentation - should be specifically noted along with other items that will - cause breaking changes during upgrades. - * Read the documentation and remove outdated parts. - * Compress the release candidate source code in .zip and .tar.bz2 - formats, and then add them to the `Download - `__ section of the ZOO-Project - website. - * Cut a release candidate once you think that everything is in - order. Announce the release candidate for review for a duration - of at least 1 week. During this time, it is also appropriate to - deploy the release candidate in production since you are - asserting that it is stable and (significant) bug free. Publish a - specific revision with this. - * If significant bugs are reported, fix and cut a new release - candidate. If no major bugs, then announce that the release - candidate has officially been promoted to the official release - (This can optionally done with a motion and support of the - PSC). - * Ensure that release exactly matches something in SVN. Tag and branch appropriately. - * Update documentation as needed. - * Announce the release on the zoo-discuss list and various media - -Creating an official release ---------------------- +Creating an Official Release +---------------------------- Release versions lead to an update in documentation and standard tarballs. This is to help future administrators repeatably create releases. - * Double check that the pages from the ZOO-Project.org web site match the current version. - * Double check that the latest build file matches the current revisions number. - * If this is a new major release create a branch and a tag, as shown - bellow: - - :: - - cd zoo-project-svn/ - svn cp trunk branches/branch-1.6 - svn cp trunk tags/rel-1.6.0 +* Double check that the pages from `the ZOO-Project.org web site `_ match the current version. +* Double check that the latest build file matches the current revisions number. +* If this is a new major release create a branch and a tag. - * If this is a major or minor relase, create a tag, as follow: +.. code:: - :: - - svn cp branches/branch-1.6 tags/rel-1.6.1 - - * Commit the tags or branches with the version numbers. - - :: - - svn commit -m 'Created branch/tags for the X.Y.Z release' + cd zoo-project-svn/ + svn cp trunk branches/branch-1.6 + svn cp trunk tags/rel-1.6.0 - * Create version archives - - :: - - export VERSION=2.6.0 - cd zoo-propject-svn - cp -r trunk zoo-project-$VERSION - cd zoo-project-$VERSION - rm -rf $(find ./ -name ".svn") - cd zoo-project/zoo-kernel - autoconf - cd ../../.. - # Remove documentation from the archive - rm -rf ./zoo-project-$VERSION/docs - tar -cvjf ./zoo-project-$VERSION.tar.bz2 ./zoo-project-$VERSION - zip -r ./zoo-project-$VERSION.zip ./zoo-project-$VERSION - scp -P 1046 ./zoo-project-$VERSION.{zip,tar.bz2} zoo-project.org:/var/www/localhost/htdocs/dl/ +* If this is a major or minor relase, create a tag. - * Update the `Download `__ section to add and link to the latest release. +.. code:: + + svn cp branches/branch-1.6 tags/rel-1.6.1 + +* Commit the tags or branches with the version numbers. + +.. code:: + + svn commit -m 'Created branch/tags for the X.Y.Z release' + +* Create version archives + +.. code:: + + export VERSION=2.6.0 + cd zoo-propject-svn + cp -r trunk zoo-project-$VERSION + cd zoo-project-$VERSION + rm -rf $(find ./ -name ".svn") + cd zoo-project/zoo-kernel + autoconf + cd ../../.. + # Remove documentation from the archive + rm -rf ./zoo-project-$VERSION/docs + tar -cvjf ./zoo-project-$VERSION.tar.bz2 ./zoo-project-$VERSION + zip -r ./zoo-project-$VERSION.zip ./zoo-project-$VERSION + scp -P 1046 ./zoo-project-$VERSION.{zip,tar.bz2} zoo-project.org:/var/www/localhost/htdocs/dl/ + +* Update the `Downloads page `_ to add the latest release (by editing `this wiki page `_). Index: /branches/PublicaMundi_David-devel/docs/install/installation.rst =================================================================== --- /branches/PublicaMundi_David-devel/docs/install/installation.rst (revision 699) +++ /branches/PublicaMundi_David-devel/docs/install/installation.rst (revision 700) @@ -212,4 +212,20 @@ $ ./configure --with-xml2config=/usr/local/bin/xml2-config +Use a Database Backend (Optional) +.................................. + +If you want to share the ongoing informations of running services +between various ZOO-Kernel instances then you should activate this +option. This way, both the *GetStatus*, *GetResult* and *Dismiss* +requests can be run from any host accessing the same database. + +.. note:: + By now, the ZOO-Kernel is not able to handle correctly the + *Dismiss* request from any host. Nevertheless, it will provide + valid response from any host, but only the host which is really + handling the service will be able to stop it and remove all the + linked files. + + Python Support (Optional)