Russ Allbery <r...@debian.org> writes: > Ben Finney <ben+deb...@benfinney.id.au> writes: > > Yet it is exactly those lock-in features that is the basis for > > arguments to put special effort into the centralised single point of > > failure. > > > For example, the centralised proprietary GitHub “pull request” is > > presented as a reason to abandon a decentralised model: > > Uh, a pull request isn't something proprietary. It was part of the > design of Git from the beginning and is based on the workflow of the > Linux kernel.
The Git pull request (‘git-request-pull(1)’) is not proprietary. I didn't claim that. Indeed, Git's ‘request-pull’ works in a federated way, allowing peer repositories on different hosting services to collaborate without needing to establish an account on each other's services. This is why the Linux repository, for example, deliberately opts to keep using the standard, federated Git ‘request-pull’ feature <URL:https://github.com/torvalds/linux/pull/17#issuecomment-5654674> and not the GitHub “pull request” feature. The GitHub pull request function is *not* compatible with Git's ‘request-pull’. It mangles them on the way in, and it doesn't produce them going out. GitHub's pull request feature is proprietary to GitHub, it can only work between repositories hosted inside the GitHub silo, and any project using that feature is thereby locking its workflow to the single-vendor GitHub service. Git repositories outside GitHub cannot interact with the GitHub pull request workflow using Git's own features. (I've done some searching to try to disprove this with recent information; if this has changed since 2010, I'd like to know <URL:https://github.com/blog/712-pull-requests-2-0>.) Emma Jane Hogbin Westby has a useful perspective on this too <URL:http://developerworkflow.com/resources/evolution-social-coding.html>. > Of course not. You don't have to use anything you don't want to use, > and no one in this thread is advocating otherwise, at least that I've > seen. If a project uses GitHub pull requests for their workflow, they are thereby prejudicing their workflow against repositories not hosted on the proprietary GitHub service. They have chosen (or have never been aware they made the choice) to make it much harder to interact with them using the existing, standard, federated Git ‘request-pull’ feature, instead opting to exclude anyone who doesn't want an account on a specific vendor's service. That's not cool, no matter how nice the UI is for the proprietary feature. That's damaging to a collaborative software community. > All that I'd ask is that, if other people want to use GitHub, for you > to not be an ass about it, the same way that we don't lecture people > for using a proprietary editor to write free sofware. Sure, so long as their decisions don't hamper anyone's ability to collaborate with them. If they use proprietary features of that tool which hampers collaboration with others in the community, I hope you'll agree that's something to object to. > Sometimes I wonder if people think free software is so fragile that if > anyone who works on it ever touches non-free software, everything we > built will crumble. I think our community and ecosystem is a lot more > robust than that. Conversely, I wonder why people are so eager to cede the power of peer collaboration by setting up single-vendor services as mediators of our peer relationships. Surely we have seen that fail far too many times to be led down that path yet again. -- \ “[…] we don’t understand what we mean when we say that [God] is | `\ ‘good’, ‘wise’, or ‘intelligent’.” —Karen Armstrong, _The Case | _o__) For God_, 2009 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/857ft9rhui.fsf...@benfinney.id.au
