[geos-devel] GEOS RFC 10 - Move Project to GitHub

Regina Obe lr at pcorp.us
Tue Nov 2 06:12:04 PDT 2021

> On Fri, Oct 29, 2021 at 12:13:19PM -0700, Paul Ramsey wrote:
> > http://libgeos.org/development/rfcs/rfc10/
> That's a 404 for me.
[Regina Obe] 
It will come back once pramsey has reset the config.  It's really because gh-pages is a branch of our core github branch
and that is not mirrored.  This problem will be solved once GEOS moves to Github.

> > GitHub has been the largest source of 3rd party code contribution via pull-
> requests for some time now.
> >
[Regina Obe] Yes it has, and we aren't going to get any more contributors than we have already because
a) We already have issues allowed to be made on Github. 
 One thing I would never agree to for PostGIS cause it just opens the flood gets for rando people to complain about how some piece doesn't work for them (whether it's packaging, I can't install, please help me do this, blah blah),
 because it's too much work to join a mailing list and complain there.

The other reason -- I like that when I do a google search for a bug the first entry that comes up has osgeo.org or postgis.net on it.
If PostGIS moved to github I'd get github.org/postgis which would just annoy me as hell "Why am I freely giving extra SEO juice to github"

b) We already accept pull requests

To the random contributor nothing has changed aside from we will only accept pull requests from Github.
But all contributors who we care about getting pull requests from already have an account on github so nothing lost here.
> >
> > 	  Easier path for new contributors to discover and assist with the
> > project

> > Moving to Github has the following components:
> >
> > 	  Move the canonical (writeable) repository to GitHub
> > 	  Migrate the (current, useful) contents of the Trac wiki to the new
> > web framework
[Regina Obe] 
It won't be a wiki anymore, but it will be part of the core website, which honestly I do think is better.
So I'm fine with this.

> Meaning it would not be a wiki anymore ?
> > 	  Deleting the migrated and out-of-date contents of the Trac wiki
> > 	  Switching the Trac tickets to read-only
> > 	  Web scraping the Trac ticket contents and placing in a
> > geos-old-tickets repo At that point:
> >
[Regina Obe] 
I honestly don't even know why this is even worth the effort.  Sounds like a lot of busy work.
Having an geos-old-tickets I think would just cause confusion.  You really should just start from scratch and copy over anything you think worthy of copying over.  If no one bothers to copy it over then it really wasn't that important.

> More dependence on single corporation being the only one which can do
> work on the infrastructure. Anyone can be a contributor on OSGeo
> infrastructure so "only they can do" is a misleading picture, as if "they" would
> not be all of us...
[Regina Obe] 
I'm fine with this.  I think Microsoft is a great steward and will be as long as there is marketing pressure for them to be.

That said -- I do worry a lot about the massive migration to Github.  
My main reason for worry (call it me being paranoid), is that eventually all open source projects will be forced to move to Github.
This means less pressure on Microsoft to be good, cause hey you have no choices.
This means people forgetting how to run their own infra, so you have no choices etc.
No need to work on making things like gitea or gitlab better, cause everyone is using Github anyway.

So everytime I hear "everyone is over here, follow us to the promised land", I loose my lunch.

> I'll only vote after reading the full RFC as I'd like to understand what the new
> management would look like. A feature I often use is marking Trac tickets as
> blockers for a milestone (we only release when all important issues are
> released), I'd like to understand how would this work on github.
> --strk;
[Regina Obe] 
Despite all my reservations, I'm still a -0 

Because though I disagree I know I don't do much work on GEOS so I don't want my vote to count
and it's the easiest way for Paul and the other core contributors to work.

The decision should be left up to the doers.

More information about the geos-devel mailing list