[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: GitHub pull requests

From: Paul Hammant <paul_at_hammant.org>
Date: Wed, 19 Jun 2019 17:59:41 +0100

One of the major GitHub social contributions to the community is the
ease of forking. I don't mean as part of a "contribution workflow",
but as a tool for getting an upstream team to change their attitude. A
famous case was Node.js and how it ended well (merged again -
http://anandmanisankar.com/posts/nodejs-iojs-why-the-fork/) but was a
smack of sorts for the maintaining company. There are others, too. I'm
talking folks that elicit changes in maintainer policy.

Generally, any viable F/OSS thing is going to end up on GitHub if it
fits (Git has size limits; GitHub have a page on limits -
https://help.github.com/en/articles/what-is-my-disk-quota). It is
going to exist there with Pull-Requests and Issues enabled by some
group.

If a team that "owns" a compelling F/OSS thing on GitHub and attempt
to not have Pull-Requests or GH issues - the thing effectively gets
taken away from them in a fork, that has that turned on. Sure, they
may insist the other "team" doesn't use their trademarks, but they
used and OSI approved license so that's all they can do.

The only defense against that is to NOT have a compelling viable project.

Well that's not absolutely true - https://github.com/mackyle/sqlite is
a fork of something that's canonical on Fossil but
https://github.com/mackyle/sqlite/network shows there's no
maintained-divergence on GH. SqLite is super viable as a project
though - things are happening to it at enough of a pace (2 or 3
commits a day) to make you overcome objections to contribute at the
source in Fossil if you want to get something into upstream. Maybe
after you tried to build it from a git-clone (assuming up to date) and
prove your patch there. However if D Richard Hipp went on a 6mo
vacation, Sqlite would have relocated to GitHub without him.

Forks are going to happen on GitHub regardless with PRs enabled. You
might as well embrace that, and play ball by leaving PRs enabled for
your repo too. Subversion's not in a shameful place if its source is
in Git. Instead it is boosted, IMO. Time was when your wire protocol
(at least WebDAV) was lingua franca. Now it's Gits: Perforce,
PlasticSCM and Mercurial all speak Git.

- Paul
Received on 2019-06-19 19:00:02 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.