61–70 of 119 posts
Earlier quoted context omitted.
> On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :) That would be one hell of an open source project: a github like UI + ticketing system but federated rather than hosted by a central authority with some kind of single sign-on mechanism.
Like GitLab?
Earlier quoted context omitted.
Centralizing the "hub" pretty much negates the distributed aspect of a dvcs, and github has no incentive to invest in extending git to be even more distributed ala fossil or bittorent, to mention two not quite fitting but conveying the point examples. Maybe git-appraisal will grow into something good.
The negation is that we centralize important data like code reviews and tickets in an external place that can be easily lost. Without those, most git repositories fail to tell the full history of a project.
Earlier quoted context omitted.
There are some things you simply can't do on GitHub: * block trolls from interacting with an organization, short of filing a support ticket * install pre-receive hooks without using the pull request infrastructure * set up status checks (the PR equivalent of pre-receive hooks) for pull requests that require force pushes, allowing some external check to replace git's usual fast-forward check * have status checks apply…
> On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :) That would be one hell of an open source project: a github like UI + ticketing system but federated rather than hosted by a central authority with some kind of single sign-on mechanism.
Earlier quoted context omitted.
> On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :) That would be one hell of an open source project: a github like UI + ticketing system but federated rather than hosted by a central authority with some kind of single sign-on mechanism.
Like GitLab?
There's potentially a way to build a system that federates all of this, and then toss GitLab on top for the UI. A good standard would be whether a newcomer could submit a PR with only one more click (for the OAuth screen) than they would need on GitHub.
Earlier quoted context omitted.
Like GitLab?
GitLab and gogs are both fine for getting 80% of the UI, but there are network effects with GitHub: that you're already signed in and have keys and such set up (although OAuth and API cleverness with keys can get you close), that your contributions across all projects show on your profile, that third-party tools like Travis know how to talk to your GitHub in particular, etc. And all sorts of little things, like that…
That way future interaction would hide the fact that the systems are in fact separate.
GitHub's reign over public open source programming is a bit terrifying. But, it's been mostly benevolent so far, but I do find it troubling to trust a private company to keep dev's in mind, and not profit.
Of course, you have issues and discussions that are tried to Github's platform, but we don't have any universally accepted format for it except email anyway.
GitHub's reign over public open source programming is a bit terrifying. But, it's been mostly benevolent so far, but I do find it troubling to trust a private company to keep dev's in mind, and not profit.
It's absurd that so many open-source and / or free software projects are happy to host their public-facing development infrastructure with a private company running proprietary software.
Earlier quoted context omitted.
The problem is with people's mindset that everything has to be on github. Large projects that dare to use self-hosted more fitting infrastructure like Phabricator tend to be punished socially.
What does "punished socially" even mean? Unable to attract as many contributors? The cold reality is that most open source projects aren't really TRYING to attract contributors. Small-time hobbyists often don't want to play with others in their personal project sandboxes, and big-time projects with high profile usually put up high barriers to contribution. Unable to attract as many end-users, or as much public mindsh…
I'd say there is a large amount of projects between these two extremes, and Github makes it relatively easy to get contributors "accidentally", by making it trivially easy to contribute. And a small percentage of those will probably stick around.
For small contributions (e.g. bugs due to different configuration of my system that are trivial to recognize and catch, errors in the documentation, properly describing a bug or crash I see) GitHub is really quick. With other projects, figuring out how to get post access to the bug tracker and how to check that the bug hasn't been reported yet, or reading up on where and how to submit code changes probably takes more time then dealing with the issue itself, and I'm not going to bother.
Not saying that other places can't be similarly quick (I'd say Bitbucket and GitLab probably are), but many projects hosted on their own infrastructure are worse about that.
Earlier quoted context omitted.
The negation is that we centralize important data like code reviews and tickets in an external place that can be easily lost. Without those, most git repositories fail to tell the full history of a project.
Joey Hess has partially solved that with his github-backup, which "is a simple tool you run in a git repository you cloned from GitHub. It backs up everything GitHub publishes about the repository, including branches, tags, other forks, issues, comments, wikis, milestones, pull requests, watchers, and stars." https://github.com/joeyh/github-backup