[MetaCRS] Participation, Infrastructure, Incubation

[Mike Adair]

Frank,

Yes, I am still very much interested in joining this for Proj4js and 
would be happy to sit on the PSC.  My preference is for a separate 
SVN/Trac for each project (for the reasons you outline below) but would 
be happy with either arrangement.

Mike

Frank Warmerdam wrote:
> 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,