[postgis-devel] PSC Vote: Move from svn to Git (and by git I mean Gitea)

Thu Oct 24 10:25:17 PDT 2019

Bborie,

Thanks for your thoughtful and calm comments.  After reading it I feel like a bit of a jerk.

I do especially like your note about

*	Given that we have an existing contribution guidelines doc, let's do a review transparently in postgis-devel so that everyone has visibility and all interested parties may express their opinions. We need to ensure "fair play" to give the community a chance to grow. Otherwise, we stay insular.
*	We need to firm up our checks and balances:

*	What are the minimum requirements of a PR? Unit tests? Integration tests (something that requires the database to be up)? Valgrind for memory leaks?
*	How many reviewers required for a PR?
*	What automated testing is required for each PR before it can be merged?  I'm talking about which test suites and on which platforms

I hadn’t given much thought to that but agree we should.

Thanks,

Regina

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Bborie Park
Sent: Thursday, October 24, 2019 12:18 PM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: [postgis-devel] PSC Vote: Move from svn to Git (and by git I mean Gitea)

Hey All,

I was hoping to keep lurking but I should probably chime in.

After reviewing the threads, these are the common themes I see:

*	Moving from svn to git for version control generally has consensus as a positive move
*	Moving from trac to a more current git development platform is where all the discussion is focused on. The volume of commentary makes sense as there are so many dimensions here (e.g. SaaS vs self-hosted, Free as in Beer vs Free as in Speech, UX preferences, Latent momentum in the greater OSS and Developer communities)

If you want to stop reading here, my suggestions are:

*	Yes to moving to Git
*	Yes to moving to GitHub

My reasons for these two suggestions are as follows:

Obviously for me to vote one way or another means I have to include my opinions (puts on fire-proof jacket)...

*	The easy one... pretty pretty please move off of svn to git. Experimentation is just easier
*	Move to github. Here are my reasons why

*	As a massive fan of bare metal, it kinda pains me to say that we should not have to think about the infrastructure upon which the tools of "how we work" run. So yes, let's just use a SaaS offering and get it over with.
*	I understand the concerns that arise when we see that Github is a proprietary platform. The platform is absolutely proprietary. The version control system underneath is OSS. So "how" we work would be on a proprietary platform, not "what" we work on. Having used GitLab and BitBucket as well, they've all got proprietary bits that may cause  concern.
*	Github was the first SaaS git dev platform that just "clicked". As such, almost every product development community defaults to Github and thus propelling it to become the standard by which all alternatives are measured.
*	Because of the traction created by Github, communities have accelerated faster than I can believe. My recent experience has all been in computer vision work with deep learning and almost every research model/project/idea is documented on Github, which then gets forked so that participants can verify the original research and iterate on new generations. I see the same patterns happening in FOSS software as well. Momentum builds and you've got a snowball moving under its own accord.
*	As for the sudden increase in exposure (I think GitHub did a fantastic job with their SEO to ensure repos are prominent in Google search results) and hopeful increase in contributors, we should firm up our contribution guidelines and the tooling we use to provide checks and balances on any PRs to master.

*	Be transparent by placing the guidelines in a prominent place
*	Given that we have an existing contribution guidelines doc, let's do a review transparently in postgis-devel so that everyone has visibility and all interested parties may express their opinions. We need to ensure "fair play" to give the community a chance to grow. Otherwise, we stay insular.
*	We need to firm up our checks and balances:

*	What are the minimum requirements of a PR? Unit tests? Integration tests (something that requires the database to be up)? Valgrind for memory leaks?
*	How many reviewers required for a PR?
*	What automated testing is required for each PR before it can be merged?  I'm talking about which test suites and on which platforms

*	I suspect most product development communities are familiar with GitHub's UX (exception being BitBucket) as I see the exact same pattern in Gitea and GitLab (GitLab essentially blended the UX patterns of GitHub and BitBucket). So, I don't see there being a usage pattern hurdle for most new contributors.

I think most of the hurdles to transitioning to Github are addressable by reviewing and updating our processes. Yes, we will lose the degree of control we have now. But I would state that by letting go with a clear set of checks and balances, we are allowing the community to move at its own pace but with us guiding it (like bumpers in bowling).

Funny that all that we're discussing happens all the time under the covers of "private business" at every startup that is fortunate to grow from one to three product developers to 300+.

-bborie

On Wed, Oct 23, 2019 at 2:57 AM Paul Ramsey <pramsey at cleverelephant.ca <mailto:pramsey at cleverelephant.ca> > wrote:

> On Oct 23, 2019, at 2:51 AM, Sandro Santilli <strk at kbt.io <mailto:strk at kbt.io> > wrote:
> 
> On Wed, Oct 23, 2019 at 02:34:49AM -0700, Paul Ramsey wrote:
> 
>> Anyone trying to review development activity or find code to review
>> has to check three places (actually four, since they should check the trac
>> issue report too). 
> 
> This is actually the reason why we want to keep Trac.
> Activity should be _only_ review/planned on Trac.

And a workflow that dupes everything doesn’t bother you? It is one of the many many roadblocks we place in the way of contributors.

This is the part where Regina chimes in and claims that road blocks are a good thing, so we have:

(a) multiple places to work branches/PRs is a good thing and
(b) deliberately making contribution is a good thing

and I don’t know what to say to folks who honestly hold those opinions. 

I hate to see all the effort lavished on all this programmer wankery that could be eliding by going to the place where the developers are. It’s not like we’re locked in, we’ve moved before, we’ll move again. We moved to different places because they provided better collaboration than the places they replaced. Recently that metric has changed to instead wanting places that provide ideological consistency for a subset of the PSC. 

CSV/nothing - Refractions
SVN/custom - Google Code
SVN/trac - OSGeo

I’d like to hear what Bborie is thinking,

P

> 
> Pull requests landing on any mirror but not having a
> corresponding Trac ticket should be just ignored, IMHO.
> 
> Note that a similar problem exists for organizations
> having many different repository hosted on GitHub,
> enough that external tools are often used to have
> a "global view" on what's going on, and easier management
> ("what's to be done before going 3.0.0 final?").
> 
> Trac has a plugin to deal with PR coming form any place
> (even from private git servers), shall we want to experiment
> with that:
> 
>    https://trac-hacks.org/wiki/PullRequestsPlugin
> 
> --strk;
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

_______________________________________________
postgis-devel mailing list
postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/postgis-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20191024/6d2a8093/attachment-0001.html>