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

Bborie Park dustymugs at gmail.com
Thu Oct 24 09:17:59 PDT 2019 

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>
wrote:

>
>
> > On Oct 23, 2019, at 2:51 AM, Sandro Santilli <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
> > https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
> _______________________________________________
> postgis-devel mailing list
> 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/9295f454/attachment.html>

More information about the postgis-devel mailing list