[postgis-devel] PSC Vote: Move from svn to Git (and by git I mean Gitea)
Bruce Rindahl
bruce.rindahl at gmail.com
Thu Oct 24 11:12:19 PDT 2019
For what it's worth I am +0
In the last 13+ years I think I have submitted a grand total of 3
contributions. Every time I have to search for how to make/apply a patch.
If there is FAQ on how to contribute or test for new users, I don't care
what is used, I will follow the directions. It is daunting to get involved
the first time for almost everyone.
Bruce
On Thu, Oct 24, 2019 at 10:51 AM Bborie Park <dustymugs at gmail.com> wrote:
> Hey Regina,
>
> You may want to label yourself as a jerk but in the end, you just care
> about the soul of the project.
>
> If anything, Sandro and you have had to bear a great deal of the day to
> day flow of the project which is a massive responsibility. But we need to
> allow the project to grow beyond ourselves and at some time, Sandro and you
> will run out of bandwidth due to the demands of said growth and burn out
> (been there, done that, lesson learned). If anything, the goal is to let
> you two focus on what you two are passionate about while letting the
> community run within the guidelines affirmed by the PSC with input from the
> community.
>
> By doing so, you can rest assumed that the codebase's quality is improving
> and freeing you up to focus on the what I think you enjoy: the user
> experience (docs, training, usage patterns and all the stuff I have found
> to be "customer success").
>
> The same goes for Sandro...
>
> In the end, my only ask is: strong opinions, weakly held
>
> -bborie
>
> On Thu, Oct 24, 2019 at 10:25 AM Regina Obe <lr at pcorp.us> wrote:
>
>> 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>
>> 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
>>
>> _______________________________________________
>> 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/8f5322b8/attachment-0001.html>
More information about the postgis-devel
mailing list