librelist archives

Re: [CAPRA Development] branching! (and release?)

From:

Sebastian Benthall

Date:

2010-05-12 @ 20:30

>
> As Ariel mentioned earlier on the librelist mailing list, a new version of
> Django is coming soon, and will provide nifty new features that will help us
> with implementing permissions in GeoNode, not just in actually getting
> permissions applied to individual records, but also in doing so in a way
> that we can reasonably expect third-party libraries to work well with.  I am
> thinking we should upgrade Django sooner rather than later in order to allow
> us to get this permissions stuff in place as quickly as possible.  I am also
> thinking that pulling the Django rug out from under the Haiti portal is
> probably not the best way to ship a solid product in the timeframe we're
> working on.
>

+1


> Some other artefacts that might be worth considering (but definitely out
> for the Haiti site):
> * GeoServer - pre-packaged with geonode extensions
> * GeoNode geoserver extensions - packaged to be installed in an existing
> GeoServer deployment
> * GeoNetwork - pre-packaged with GeoNode schemata
> * GeoNodePy - for those who eschew the devkit for whatever reason
> * docs - well, you know
>
> I think the development kit is more important in the immediate term,
> especially since we are maintaining a live demo based on that deployment
> bundle.  That development kit is a little weak, but I think that's okay for
> an 0.1 release.  However, just for the record, here are some ideas I have
> for it:
> * some canned deployment bundle builder that helps in packaging up a
> customized site for deployment the way we do with the capra site now
> * documented means for developing GeoServer process extensions and
> JavaScript extensions that get included in that deployment bundle
> * a tool to set up a new django site with the GeoNode stuff hooked up, the
> way that django-admin.py startproject does for general django sites.
>

I think we should prioritize these improvements as we bump into them for
internal needs until we get user demand for this.

So, over the course of the next month or so:
  - Ivan will be deploying MyHazard Haiti Web Portals
  - Ariel will be taking over the CAPRA GeoNode, and updating presumably
according to a stable release schedule
  - We'll be setting up the generic GeoNode demo instance on a
geonode.orgserver, to be updated from trunk.

As we go, any work we can do to streamline these processes can be
prioritized as an improvement to our deployment story, which is something
Stu is very concerned with.

I believe I have mentioned this before, but I'd also like to see the
> CAPRA-specific stuff move to a separate subdirectory of the repository than
> the "core" geonode code.
>

+1

Let's do this cleanup this month as part of the community building push.


> Anyone want to weigh in regarding:
> * release criteria (how do we know when the 'node is good enough or
> different enough from the previous release to tag a new one)
>

I think that there aren't any hard and fast rules at this point, so in the
short term this should just be a decision made periodically by the steering
committee based on whatever factors seem to be coming up.


> * release process (what do we change in the repo, what do we do with the
> code, where do we put any artefacts)
>

I think it would make sense to have a "download stable release" section on
geonode.org

and then links/quickstarts for developers for those that want to work with
or on trunk.


-- 
Sebastian Benthall
OpenGeo - http://opengeo.org

Excellent timing David.

Django 1.2 final should be out anytime now (1.2 RC was a week ago).

[...]

> * a tool to set up a new django site with the GeoNode stuff hooked up, the
>> way that django-admin.py startproject does for general django sites.
>
> [...]

We may want to have a "clonable" (git?) main project in github instead of
generating templates like django-admin does. This improves the chances of
getting back contributions and eases keeping up with new versions. I believe
we should follow what django-mingus and Satchmo do(starting project ready to
just set local_settings.py), instead of what Pinax does (pinax-admin.py
startproject).

Ariel.