Changeset 700
- Timestamp:
- Jun 30, 2015, 1:45:09 PM (9 years ago)
- Location:
- branches/PublicaMundi_David-devel/docs
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
branches/PublicaMundi_David-devel/docs/contribute/contributors.rst
r696 r700 13 13 * Venkatesh RAGHAVAN (aka venka) 14 14 15 ZOO Project Steering Comitee 16 ---------------------------- 17 18 The ZOO Project Steering Comitee is responsible to manage the project 19 which is maintained, improved, and supported by a small but growing 20 developer community. The PSC is composed of the following people (by 21 alphabetical order): 22 23 * Nicolas BOZON (`GeoLabs SARL <http://geolabs.fr>`_), FR 24 * Maria Antonia BROVELLI (`Politecnico di Milano 25 <http://www.polimi.it>`_), IT 26 * Massimiliano CANNATA (`SUPSI <http://www.ist.supsi.ch/>`_), CH 27 * Gérald FENOY (`GeoLabs <http://www.geolabs.fr/>`_), FR **(Chair)** 28 * Hirofumi HAYASHI (`AppTech <http://www.apptec.co.jp/>`_), JP 29 * Daniel KASTL (`Georepublic <http://georepublic.de/en/>`_), DE 30 * Jeff McKENNA (`Gateway Geomatics 31 <http://www.gatewaygeomatics.com/>`_), CA 32 * Markus NETELER (`Fondazione Edmund Mach 33 <http://gis.fem-environment.eu/>`_), IT 34 * Venkatesh RAGHAVAN (`Osaka City University 35 <http://www.osaka-cu.ac.jp/index-e.html>`_), JP 36 * Angelos TZOTSOS (`National Technical University of Athens 37 <http://users.ntua.gr/tzotsos/>`_), GR 38 39 40 15 41 ZOO-Project Commiters 16 42 --------------------- … … 24 50 * Luca DELUCCHI (aka lucadelu) 25 51 * René-Luc D'HONT (aka reluc) 26 * Gérald FENOY (aka djay) 52 * Gérald FENOY (aka djay) **Admin** 27 53 * Knut LANDMARK (aka knut) 28 54 * Jeff MCKENNA (aka jmckenna) … … 39 65 40 66 * Thomas GRATIER 41 * Hirofumi HAYASHI42 67 * Guillaume SUEUR 43 68 * Daisuke YOSHIDA -
branches/PublicaMundi_David-devel/docs/contribute/release.rst
r699 r700 1 1 .. _contribute_release: 2 2 3 Release procedure4 ================= ===============3 Release Procedure 4 ================= 5 5 6 General rules 7 ------------------ 6 * 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. 7 * If not already created, create a wiki page (like this `this one <http://zoo-project.org/trac/wiki/Release/1.3.0/Notes>`_ using this scheme: Release/M.m.r/Notes), summarizing changes from the previous release (extracted from the `revision log <http://zoo-project.org/trac/browser/trunk/zoo-project/HISTORY.txt>`_). 8 * 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. 9 * Read the documentation and remove outdated parts. 10 * Create release candidate as .zip and .tar.bz2 then add them on this `page <http://zoo-project.org/site/Downloads>`_ (by editing this `wiki page <http://zoo-project.org/trac/wiki/Download>`_) 11 * 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. 12 * 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). 13 * Ensure that release exactly matches something in SVN. Tag and branch appropriately. 14 * Update documentation as needed. 15 * Announce on various email list and other locations (news_item@osgeo.org, SlashGeo, etc) 8 16 9 The ZOO-Project release procedure is commonly defined by the following rules: 10 11 * 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. 12 * It is first needed to create a wiki page summarizing the changes from the previous release (extracted from the revision log file called 13 `HISTORY <http://zoo-project.org/trac/browser/trunk/zoo-project/HISTORY.txt>`__ ). 14 * That wiki page should include new features, changed features, and 15 deprecated features if any. Changes to the official documentation 16 should be specifically noted along with other items that will 17 cause breaking changes during upgrades. 18 * Read the documentation and remove outdated parts. 19 * Compress the release candidate source code in .zip and .tar.bz2 20 formats, and then add them to the `Download 21 <http://zoo-project.org/Download>`__ section of the ZOO-Project 22 website. 23 * Cut a release candidate once you think that everything is in 24 order. Announce the release candidate for review for a duration 25 of at least 1 week. During this time, it is also appropriate to 26 deploy the release candidate in production since you are 27 asserting that it is stable and (significant) bug free. Publish a 28 specific revision with this. 29 * If significant bugs are reported, fix and cut a new release 30 candidate. If no major bugs, then announce that the release 31 candidate has officially been promoted to the official release 32 (This can optionally done with a motion and support of the 33 PSC). 34 * Ensure that release exactly matches something in SVN. Tag and branch appropriately. 35 * Update documentation as needed. 36 * Announce the release on the zoo-discuss list and various media 37 38 Creating an official release 39 --------------------- 17 Creating an Official Release 18 ---------------------------- 40 19 41 20 Release versions lead to an update in documentation and standard tarballs. This is to help future administrators repeatably create releases. 42 21 43 * Double check that the pages from the ZOO-Project.org web site match the current version. 44 * Double check that the latest build file matches the current revisions number. 45 * If this is a new major release create a branch and a tag, as shown 46 bellow: 47 48 :: 49 50 cd zoo-project-svn/ 51 svn cp trunk branches/branch-1.6 52 svn cp trunk tags/rel-1.6.0 22 * Double check that the pages from `the ZOO-Project.org web site <http://zoo-project.org/>`_ match the current version. 23 * Double check that the latest build file matches the current revisions number. 24 * If this is a new major release create a branch and a tag. 53 25 54 * If this is a major or minor relase, create a tag, as follow:26 .. code:: 55 27 56 :: 57 58 svn cp branches/branch-1.6 tags/rel-1.6.1 59 60 * Commit the tags or branches with the version numbers. 61 62 :: 63 64 svn commit -m 'Created branch/tags for the X.Y.Z release' 28 cd zoo-project-svn/ 29 svn cp trunk branches/branch-1.6 30 svn cp trunk tags/rel-1.6.0 65 31 66 * Create version archives 67 68 :: 69 70 export VERSION=2.6.0 71 cd zoo-propject-svn 72 cp -r trunk zoo-project-$VERSION 73 cd zoo-project-$VERSION 74 rm -rf $(find ./ -name ".svn") 75 cd zoo-project/zoo-kernel 76 autoconf 77 cd ../../.. 78 # Remove documentation from the archive 79 rm -rf ./zoo-project-$VERSION/docs 80 tar -cvjf ./zoo-project-$VERSION.tar.bz2 ./zoo-project-$VERSION 81 zip -r ./zoo-project-$VERSION.zip ./zoo-project-$VERSION 82 scp -P 1046 ./zoo-project-$VERSION.{zip,tar.bz2} zoo-project.org:/var/www/localhost/htdocs/dl/ 32 * If this is a major or minor relase, create a tag. 83 33 84 * Update the `Download <http://zoo-project.org/Download>`__ section to add and link to the latest release. 34 .. code:: 35 36 svn cp branches/branch-1.6 tags/rel-1.6.1 37 38 * Commit the tags or branches with the version numbers. 39 40 .. code:: 41 42 svn commit -m 'Created branch/tags for the X.Y.Z release' 43 44 * Create version archives 45 46 .. code:: 47 48 export VERSION=2.6.0 49 cd zoo-propject-svn 50 cp -r trunk zoo-project-$VERSION 51 cd zoo-project-$VERSION 52 rm -rf $(find ./ -name ".svn") 53 cd zoo-project/zoo-kernel 54 autoconf 55 cd ../../.. 56 # Remove documentation from the archive 57 rm -rf ./zoo-project-$VERSION/docs 58 tar -cvjf ./zoo-project-$VERSION.tar.bz2 ./zoo-project-$VERSION 59 zip -r ./zoo-project-$VERSION.zip ./zoo-project-$VERSION 60 scp -P 1046 ./zoo-project-$VERSION.{zip,tar.bz2} zoo-project.org:/var/www/localhost/htdocs/dl/ 61 62 * Update the `Downloads page <http://zoo-project.org/site/Downloads>`_ to add the latest release (by editing `this wiki page <http://zoo-project.org/trac/wiki/Downloads>`_). -
branches/PublicaMundi_David-devel/docs/install/installation.rst
r696 r700 212 212 $ ./configure --with-xml2config=/usr/local/bin/xml2-config 213 213 214 Use a Database Backend (Optional) 215 .................................. 216 217 If you want to share the ongoing informations of running services 218 between various ZOO-Kernel instances then you should activate this 219 option. This way, both the *GetStatus*, *GetResult* and *Dismiss* 220 requests can be run from any host accessing the same database. 221 222 .. note:: 223 By now, the ZOO-Kernel is not able to handle correctly the 224 *Dismiss* request from any host. Nevertheless, it will provide 225 valid response from any host, but only the host which is really 226 handling the service will be able to stop it and remove all the 227 linked files. 228 229 214 230 215 231 Python Support (Optional)
Note: See TracChangeset
for help on using the changeset viewer.