Jeroen and others,
Please see my comments below:
Thanks.
John
-----Original Message-----
From: geonetwork-devel-admin@lists.sourceforge.net
[mailto:geonetwork-devel-admin@lists.sourceforge.net] On
Behalf Of Jeroen Ticheler
Sent: Tuesday, 23 May 2006 11:28 PM
To: Geonetwork-devel
Subject: [Geonetwork-devel] Project management discussionHi all,
Although this shouldn't become an unmanageable discussion
I think
it is very important to take the project management issue up on the
mailing list to ensure we get the most workable project management
for all.Some context:
- We are facing a very exciting and challenging time at the moment
with a very fast growing user and developer community. So its
time to
raise some project management issues and this email intends
to do that.
- Currently we use SourceForge.net software development tools
for the
development. We use a limited set of them of which the CVS, the
mailing lists and file release system are the main ones. The
trackers
are also used, but not very consistently.
- We also have a Plone based Community website that is used for
Documentation (user, editor, admin and developer) and
Software releases.
- At the Second GeoNetwork workshop, one of the decisions was
to move
the project into the newly created OSGEO foundation (http://
www.osgeo.org) once that foundation is more stable,
infrastructure is
in place and the incubation process is open to new projects. Moving
GeoNetwork opensource into OSGEO is seen as a strategic step to
facilitate closer integration with complementary software in the
geospatial arena, especially the java stack, but not excluding
applications like MapServer, GRASS, GDAL etc...
- Current development versus future development. I see two clear
phases in the near future:
- First we are working on the release 2.1 of the software that
includes CSW 2 support (ISO 19115/19119 profile, ISO 19139 validated
metadata support and a range of smaller improvements.
- Second we will be working on the design of GeoNetwork
opensource
version 3.0. Some of the upcoming requirements will most likely need
redesigning parts of the architecture.
The consequence is that we need to find the most practical solution
that does not limit our current work towards version 2.1 but at the
same time provides new developers with the options to follow what's
going on and what they can do.
Work on version 3 will most likely overlap to a large extent
with the
incubation process into OSGEO. The design part will most
likely start
before this incubation process starts, so we need a facility to
support this without running into a situation where we are forced to
go into an additional migration procedure. I will write to the OSGEO
Incubator Committee to see if there are options to start using some
WIKI pages for instance on the OSGEO site if that would be a desired
way to proceed(?).OK, that provides quite a bit of context. Now, what can we do
towards
the future and what tools should we use in the future?Code management: The general trend seems to be to move the code into
Subversion instead of CVS. OSGEO is setting up Subversion and
SourceForge also provides SV since some months. I think we should
consider moving the code into SV after the release of version
2.1 and
use SV from version 3.0 onwards.
I'm happy with either. I personally won't be providing bug fixes etc.
because I don't get a chance to use Java that often. However, I do have my
finger in a couple of pies and will provide encouragement ;--) through those
resources. I think that there is a need to allow some sort of code
development tracking with branching such as CVS and Subversion provide.
Mailing lists: Nothing to be changed. We will create one more
mailing
list for the advisory board that was formed during the workshop.
There may be a need for one more list if we were to start using a
system that reports on a regular basis on CVS/SV changes and tracker
changes.
I would like to see the minimal number of mailing lists. I have found that
they often overlap and cross posting may become a problem if there are too
many. However, the advisory board sound like a special case and should
probably be created.
I don't think that there should be a CVS/Subversion list. An email to the
developers list notifying the release of bug fixes or new versions should be
enough. The list isn't over busy so I don't think it will be that annoying.
;--)
Trackers: This is an area for improvement. There are several options
here; SourceForge's, JIRA, The facilities in the Plone Software
center (although I think they are not so elegant), ...??
We need something for task assignment, bug tracking, time
management/
scheduling
I have only had experience with the ISO 19139 issue tracker used for the ISO
19139 XSDs. It seemed to work fine. I have no preferences regarding which
software to use.
Architecture development, road map development et cetera. We again
have several options. The decision should best fit with what
OSGEO is
going to use but they are not clear on this themselves yet. Options
are: The Community website (some functions can be covered by that
(e.g. WIKIs) but not all), Collabnet (now in use by OSGEO but not
sure they will keep it, Codehaus (used by e.g. many of the
Java based
software like GeoServer, uDig, GeoTools), ...???
I think that having some WIKI pages could be useful here, but ideas
and experiences are very welcome!
Architecture is very important. I believe that GeoNetwork should be
developed using "plug in" web services as much as possible. This will allow
people to use the Metadata Editing Tool (MET) component with their own
Catalogue Services, search system, web map client, web feature client or web
coverage clients. These are all based on OGC and ISO 19100 specifications so
they should be interoperable. I personally like to mix and match the best
from different areas.
Discussion could still be via the developers list with maybe a wiki or bug
tracker for display or download of proposals. Attachments to emails often
fill up email post offices and are sometimes blocked. Sometimes that can't
be viewed because of the need for proprietary software. Downloading images
onto a wiki or bug tracker will best service this need to exchange diagrams.
Sorry for this long email, I hope it will prove a useful starting
point however.
Keep up the good work. I have great hopes for GeoNetwork. Otherwise I will
have to hassle some other MET development. ;--)
Ciao,
Jeroen
_______________________
Jeroen Ticheler
FAO-UN
Tel: +39 06 57056041
http://www.fao.org/geonetwork
42.07420°N 12.34343°ERqºyvy²¢y®zr·¶}?Ë?S'yr-¶'ºm?£¡mz¦q¢®¿mv¥x¢¢§zº-±