[MetaCRS] Participation, Infrastructure, Incubation

Gary Crawford gary.crawford at autodesk.com
Wed Apr 16 13:54:01 EDT 2008


I'd like to propose adding Hugues Wisniewski to the bootstrap PSC list.

Gary.



-----Original Message-----
From: metacrs-bounces at lists.osgeo.org [mailto:metacrs-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam (External)
Sent: Wednesday, April 16, 2008 8:30 AM
To: metacrs at lists.osgeo.org
Subject: [MetaCRS] Participation, Infrastructure, Incubation

Folks,

I have been negligent in following up on the effort to establish a
MetaCRS umbrella project for a number of projection and coordinate system
related efforts.

Participation
-------------

First, we have representatives of CS-MAP (Norm Olsen and a few other
Autodeskers), PROJ.4 (myself), and proj4js (Rich Greenwood and Mike Adair)
on the list and presumably these will be our founding projects.

I have contact Gerald Evenden and he is supportive of libproj4 also
being part of the MetaCRS effort, especially as part of a refactoring
of PROJ.4 to use libproj4 for it's base level projections and keeping
CRS/datum/etc services as a distinct layer.

I get the impression from Norm that CS-MAP is ready or nearly ready
to move out as open source, is that right?

Mike has been prompting me for a few months, so it seems that proj4js
is still quite interested - right Mike/Rich?

Infrastructure
--------------

One upcoming step is establishing infrastructure in terms of a bug
tracker and svn instance.  There are two main approaches to this.

1) We have a distinct Trac and SVN for each library/subproject.

2) We have a shared Trac and SVN for everything.

I am leaning towards having one trac and one svn for everything mainly
for reduced system administration overhead, and because it lets us work
towards sharing some components more effectively (such as common dictionary
files, and test files).  The downside that occurs to me is that the Trac
roadmap and version features will be confusing when used with several
subprojects at once.

For instance, the /roadmap will need to have subproject prefixes or something
on versions which will mean the roadmap might show proj-4.6.1, proj-4.7.0,
csmap-a.b.c, csmap-a.d.0, proj4js-2.3.0.  Likewise when a ticket is entered
we will have to offer all versions of all subprojects in the versions list
and will presumably end up having a bunch of components for each subproject.

The more I think about this the more messy it seems to me.

Note this is quite different than Bugzilla which has a builtin idea of having
several projects in one bugzilla.

Well, thoughts are welcome on how to handle this!  But we should try and
settle this fairly soon and request OSGeo for service hosting.

Incubation
----------

I would also like to draft apply for incubation with OSGeo.  Our project
is somewhat unorthodox being a set of loosely related projects.  As such,
once we get into incubation I think we will be there quite a while till
we work out our project dynamics.

A related aspect is governance.  I would like to suggest a preliminary
Project Steering Committee consisting of:

Frank Warmerdam (Chair)
Norm Olson
Mike Adair
Rich Greenwood

to bootstrap things.  I would forsee the PSC then setting itself a
governance document (aka RFC1), and being the core group that makes
decisions on infrastructure, procedures, adding new members, commiters,
etc.

Any thoughts?

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
MetaCRS mailing list
MetaCRS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/metacrs


More information about the MetaCRS mailing list