As far as the management of the CAPRA code with contracts that is something that can be figured out. However it is useful to keep the CAPRA code around as we will be installing an instance of the GeoNode on the CAPRA website so we will still need the AME storage ability.
----
Galen B. Evans
Disaster Risk Management
Latin America & The Caribbean
Sustainable Development Network (SDN)
World Bank
1818 H St. NW
Washington, DC 20433
+1-202-458-5344
Sebastian Benthall ---08/10/2010 08:34:27 PM---One thing we need to do before the 1.0 release is remove the CAPRA specific stuff from the generic c
 From: | Sebastian Benthall <[email protected]> |
To: | [email protected] |
Date: | 08/10/2010 08:34 PM |
Subject: | [geonode] Splitting off the CAPRA code |
Sent by: | [email protected] |
| |
| |
One thing we need to do before the 1.0 release is remove the CAPRA specific stuff from the generic codebase and deployment available at master.
Conveniently,the CAPRA-specific stuff is in src/GeoNodePy/capra and src/capra-client. The only non-CAPRA specific things I can find in those directories are the templates and default settings for the the new user registration.
I propose that as an interim solution to this problem, we
* Move the user registration code to src/GeoNodePy/geonode
* Make a 'capra' branch on Github/geonode, leaving the capra-specific directories in it
* Remove the capra directories from 'master' and 'synth'
If there are no objections, I'll work on this this week.
In the longer term, it would probably make sense for there to be a github/capra (or something) repository with its own GeoNode fork. However, I haven't spoken with anyone at the World Bank about how they want to manage or brand their internal code, and I think there are a lot of open questions about how we are going to technically manage contract work around GeoNode, including work for CAPRA, and
[See ticket http://projects.opengeo.org/CAPRA/ticket/688 ]
--
Sebastian Benthall
OpenGeo - http://opengeo.org
