[Proj] Migrate to github?

[Roger Bivand]

Howard Butler <howard <at> hobu.co> writes:

> 
> 
> > On Mar 15, 2015, at 10:37 PM, Hermann Peifer <peifer <at> gmx.eu> wrote:
> > 
> > On 2015-03-15 14:25, Charles Karney wrote:
> >> 
> >> What I think is unacceptable is a 3-year interval between releases for
> >> proj4.  (4.8.0 was released on 2012-03-13; 4.9.0 was never released;
> >> 4.9.1 was released on 2015-03-04.)
> >> 
> >> Howard Butler stepped up after a long period of inactivity to make the
> >> latest release of proj4 happen.  I'm strongly inclined to defer to his
> >> wishes going forward in the hope that we can see more timely releases.
> >> 
> > 
> > I can only blow into the same horn: it hurted me seeing PROJ.4 moving 
> > towards abandonware, as e.g. confirmed by fact of release 4.9.0 being 
> > abandoned.
> > 
> > From my somewhat simplistic use-PROJ.4-from-source perspective, the 
> > issue boils simply down to: "svn up" vs. "git pull". If I had to choose 
> > between abandoned code and bug reports in a politically correct 
> > repository vs. actively maintained code at github.com or similar: life 
> > is too short for not choosing the latter option.
> > 
> > There is also: 
> > https://help.github.com/articles/support-for-subversion-clients/, for 
> > those who have a preference for: svn up.
> 
> Hmm, I didn't expect my proposal to move to github would be controversial.
I know that Trac is a PITA,
> especially OSGeo's somewhat custom UserID implementation, and while going
through the tickets it
> appeared to me that if it was easier to contribute, there would be more
contribution. In my opinion, it is
> undeniable that github makes it much easier for people to contribute. I
have seen this in projects I've
> managed, projects I've participated in, and projects I've contributed to. 
> 
> ...
> 
> ...
> Even if a contributor gets over the login hump, that type of contribution
ends up being buried in Trac
> instead of in front of other potential contributors. 
> 
> ... This is not because it has failed in any way, it is simply because people
> have moved on. It's the same thing for Google Code too. And someday in the
future, the probability is not
> zero the same will happen to github too. 
> 
> ... A
> geriatric project like proj.4 needs to make it easy for outside
contributors to hop in and contribute
> without friction. Artificial barriers, purposeful or not, waste that
developer attention.
> 
> A number of OSGeo projects use github for hosting, as do plenty of
LocationTech ones as well. I'm
> comfortable using it for my projects (http://github.com/PDAL/PDAL) too.
For a small audience, big
> impact project like proj.4, it's a well-matched venue.

I apologise for pruning, but am posting via Gmane. As you'll have gathered,
I don't think that things are this simple. 

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

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

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?

I agree that it is probable that the fashion for github will recede in some
years. Maybe git will continue, it isn't unuseful, but seems better suited
to front-end work. 

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. 

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.

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. 

My conservatism is also driven by a feeling of responsibility, in my case
for many students and researchers using sp and rgdal in R, and through them
proj4, for handling spatial data. Just keeping things running is plenty of
work. 

In any case, I guess everyone will follow a lead, we certainly will.

Best wishes,

Roger


> 
> Howard
> _______________________________________________
> Proj mailing list
> Proj <at> lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
> 
>