On Sat, 18 Apr 2015 11:44:34 +1000 Ben Finney <ben+debian@benfinney.id.au> wrote: > Russ Allbery <rra@debian.org> writes: > > > Steve McIntyre <steve@einval.com> writes: > > > Agreed - it's really annoying to see everybody clamour for a > > > centralised single point of of failure for git hosting. :-( > > > > Funny, this is why I don't get why people are so upset that some use > > GitHub. Because of how Git works, the impact of lock-in is pretty > > much limited to the non-repository stuff (issues and so forth). > > 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. That just ignores the whole point of using github in the first place. github is *not* lock-in. It is the opposite of lock-in because it allows me to push free software from a locked-down corporate server to a mirror that makes it easier for me to accept contributions from people without those people needing to register with my particular corporate server. > For example, the centralised proprietary GitHub “pull request” is > presented as a reason to abandon a decentralised model: No - it is presented as a method of retrieving useful contributions which would not have been made via other methods. That contribution can then be reviewed, pushed to the internal corporate review frontend by one of the team whilst retaining the author details of the github user and that user then gets a listing in the corporate git master branch if the patch is accepted. The github pull request is just a nice UI over a patch. What on earth is wrong with that? > Paul Tagliamonte <paultag@debian.org> writes: > > > An entirely fair point, however, I also think it's quite rude to > > ignore the workflow they've chosen for contributions -- if they > > expect PRs, it might disrupt their workflow and result in a much > > harder time for them. > > So upstream have chosen a proprietary lock-in service for their > workflow. That should not put any obligation on others to also submit > to proprietary lock-in. That ignores the whole point of a DVCS - to have multiple remotes. This is about extending access, of removing lock-in. Pushing to github *increases* access, it does not invole lock-in on any level. I've chosen to offer github pull requests on all my free software because that allows me to access contributions which would otherwise be awkward to handle. The BTS, whilst excellent at so many things, is simply not designed to track git branches. One-off small patches, yes. Large changes which evolve over a period of time and keep track of changes elsewhere? umm, no - really, no and neither should it become so. Github provides that service and the people who are offering this code want to use it. Why would I refuse to use that service to open up my own locked-down server without the admin hassle of creating hundreds of new accounts? The people are already on github - if I want their contributions, what is the sense in *not* pushing to github as one of my remotes? -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpoJc3r6LBOs.pgp
Description: OpenPGP digital signature