[Proj] Migrate to github?

Howard Butler howard at hobu.co
Tue Mar 17 10:54:26 EST 2015

> On Mar 16, 2015, at 3:11 PM, Roger Bivand <Roger.Bivand at nhh.no> wrote:
> One reason is that we really don't want outside contributors or hip
> developers without insight into the history and traditions of actually doing
> projections on computers making random changes. The level of specialist
> expertise needed is considerable. I know that I don't have it, but I'd be
> very concerned about pull requests bazaar style becoming the norm

The protection against your concern is better tests and better testing of release candidates, not limiting who can contribute. I'll grant you the maths are specialized knowledge, but a significant chunk of the ticket traffic is your normal workaday library and management stuff, not intricacies of the maths. Nearly all of my ticket efforts in the run up to the 4.9.1 release was this workaday stuff, no maths.

> Another is that there is no agreement that all projects are suited by a
> decentralised model for repositories. 

A centralized repository supposes a group of folks with the wherewithal to manage, curate, and administer that software project. PROJ.4 clearly doesn't have that anymore (and I would posit it never did -- it just had ready access to Frank and he was able to justify spending his time one it). It has a bunch of users who care but aren't empowered to make the changes they need to happen. I stepped in to do the release because my software, PDAL, depends heavily on a working PROJ.4, and I'm special in that I'm a MetaCRS member with commit access in the repository. I have historically never been a PROJ.4 developer, and without my having been previously blessed, I otherwise would have been stuck. 

A way forward is for PROJ.4 to be in (low) maintenance mode with wide contribution for any/all who feel empowered to do so, along with some people who have the authority to make a release happen. Subversion and a stove-piped Trac instance cut very hard against that mode of operation. The alternative is (no) maintenance mode with almost no one having access to the revision control to maintain the software and waiting extremely long periods between releases. No one has been comfortable with the latter scenario. 

Let's try something different. I'm willing to step in as a release manager for PROJ.4, and help out where I can and shepherd release activity. I'm also not very comfortable on the maths, but I'm willing to react to testing, and I have enough confidence on other typical open source software development activities. I want to solicit more contribution. Expertise can be acquired, historical rational can be learned, and tests can be satisfied. People will invest the time if they know that it can lead somewhere useful for them. 

> Yet another is the consideration that some jurisdictions may block a domain
> for whatever reasons. Currently proj is hosted on osgeo.org for everything,
> but if the code repository is elsewhere, will the releases also be hosted
> elsewhere?

This would frankly be worse if osgeo.org were blocked in China or whatever. The organization has no financial or legal capacity to fight anything like that. github will.

> I believe that many scientists rely on proj to deliver research results of
> importance, results that can be predictably reproduced from securely run and
> archived repositories. 

The organization that produces the release, MetaCRS, will still be responsible for promoting and releasing it. That will not change regardless of the revision control or ticket tracking system that is used.

> I don't think that I'm being unnecessarily critical - finding and resolving
> the init bug #229 and the uoff bug #239 show that I've been trying to track
> where changes in proj break stuff in its use in R, and I'm grateful for the
> resolution of these issue. However, I don't think that a quick shift to
> github will solve the longer term problem of managing the project. Does
> MetaCRS still exist? Should its PSC help decide? Could you put up an RFC
> with a time line? Just getting handwaves on a list is too ad-hoc - I've seen
> it happen before and it wasn't a constructive experience.

I'm not going to write an RFC for this. I will put a test ingest up for discussion, and when we feel ready, I will motion to the MetaCRS committee to get sign off on a github migration. 

> If you believe that this has to be done your way, it also implies affirming
> your responsibility for the project in the long term, which, given your
> other major commitments, is maybe over-generous. 

I have a project and financial stake in making sure PROJ.4 is a viable software library going forward. Without the PROJ.4, libgeotiff, OSR triumvirate, I need to find new software to support horizontal and vertical coordinate transformation for 3D geospatial point cloud data. I don't have the funding available to build something from scratch, and moving to something like CS-Map is going to cost more money and time. I won't be migrating PROJ.4 to github and walking away. My contribution history to this and other OSGeo-sphere projects should make that clear.


More information about the Proj mailing list