Live data from Hacker News

Python moves to GitHub

mail.python.org

71–80 of 119 posts

Re: Python moves to GitHub

#71

Earlier quoted context omitted.

Because of how Git is a distributed model, hosting your project on Github shouldn't be a big deal. You could host your project privately and then just have Github mirror that private host with hooks. Git being distributed means that you can host your project on as many different places as you want. And making the workflow to accept pull requests for Github, Gitlab, or other providers really isn't very difficult. They…

Because of how Git is a distributed model News flash: the number of people using the "D" in "DVCS" is so tiny that it might as well not be there. Central server with central authoritative repository, where all developers push and pull and synchronize, is how people use git in the real world, and it's time to stop pretending that any distributed features will ever be used. (which is to say, if github disappeared tomor…

I think that's a different reading of what Distributed means for DVCS.

Git is about everyone having a full copy of a repo so they can go through the entire history and branch and commit freely. To actually move a project forward amongst several devs there will inevitably have to be synchronization using push/pull so there's no way to escape that.

Re: Python moves to GitHub

#72
post #47

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.

What's the alternative? Everyone running their own little proprietary stacks with none of the features or community or ease of use?

Re: Python moves to GitHub

#73
post #39

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.

Fossil [1] repositories include a distributed bug tracker (and also a distributed wiki and a distributed time-based notes system), and provides a browser-based UI.

I've only read about it, not played with it, so don't know how close it comes to what you are envisioning.

[1] http://fossil-scm.org/xfer/doc/trunk/www/index.wiki

Re: Python moves to GitHub

#74
post #47

Earlier quoted context omitted.

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.

What's the alternative? Everyone running their own little proprietary stacks with none of the features or community or ease of use?

Why would a free software project leave GitHub just to run a proprietary "stack"?

You could try one of the self-hostable free software alternatives listed here: https://en.wikipedia.org/wiki/Comparison_of_source_code_host...

Re: Python moves to GitHub

#75
post #47

Earlier quoted context omitted.

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.

What's the alternative? Everyone running their own little proprietary stacks with none of the features or community or ease of use?

It's easier than pull requests, to email a patch.

Re: Python moves to GitHub

#76

Everyone is moving to GitHub these days. Why doesn't Gitlab.com get more love? Isn't their whole stack open source?

I have three personal reasons for preferring Github to Gitlab. I'm not going to talk about the community edition of Gitlab, since Github Enterprise is a separate topic and frankly I think most individual developers couldn't be bothered to download, run, and maintain their own Gitlab instance (as evidenced by the fact that Github.com is so damn popular). 1. Gitlab themselves admit that Gitlab.com is bad[1]. Making a c…

> At best, it's a clone of Github's UI.

What I don't understand right now is why they aren't trying to copy GitHub as much as possible ... when it makes sense of course. I've been studying both GitHub and GitLab's design in detail, because I want to incorporate my technology into their branches and commits page, and I've found the user experience between both quite striking.

When I get some time this week, I would like to submit an issue with GitLab to let them know in more detail what I think they can do better, but here is just a synopsis:

- I still can't put my finger on it, but there is something off about the font.

- Avatars with 50% border radius is a bad design choice in my opinion. The problem with creating circular avatars is they hide too much of the image and they create a focal point towards the center of the image. If your avatar doesn't have a natural center focus, it will look bad and create unnecessary eye strain, since your mind will naturally try to fill in cropped areas. Keep it simple and use a simple border radius of 8 or less.

- Avatars on the commits page are too small. I'm not sure if this design decision was the result of the Gitorious acquisition, but Gitorious had this problem as well. Using small avatars has its place, but not on the commits page since this page is designed to help you better understand who did what quickly.

- How the commit message is revealed in the commits page is too jarring. If you click on the ellipses at

https://gitlab.com/gitlab-org/gitlab-ee/commits/master

and

https://github.com/gitlabhq/gitlabhq/commits/master

you'll better understand. The problem with GitLab's implementation is the strong focal point is the avatar and when you click on the ellipsis, your eyes will get dragged down with it when the message is revealed. Just copy GitHub and use a bigger avatar and have the commits message reveal below the strong focal point (avatar)

- The calendar icon on the commits page is visually too strong and should be removed.

- The clipboard and other elements on the commits rows creates an unnatural balance/flow. If you look at GitHub's commits page, the clipboard, commit sha and browse tree icon are equally balanced in size and weight, which creates a natural horizontal flow. You can sweep from left to right and it won't create any unnecessary jarring effect.

This is just some of the things that I've thought about when I was looking at the commits page and I really don't understand why they aren't copying GitHub's UI in a lot of places. The amount of money that GitHub is investing in their UI vs GitLab's is quite significant, and it should be obvious that GitHub is way more capable of producing a better user experience, so why not copy it?

Re: Python moves to GitHub

#77
post #73

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.

Fossil [1] repositories include a distributed bug tracker (and also a distributed wiki and a distributed time-based notes system), and provides a browser-based UI. I've only read about it, not played with it, so don't know how close it comes to what you are envisioning. [1] http://fossil-scm.org/xfer/doc/trunk/www/index.wiki

It's a good idea! However, the distributed nature seems to make it sufficiently involved as to preclude a good UI (e.g., issues seem to use hashes), and the simple fact of not being git, regardless of whether it's better than git, is a serious problem for adoption. Bitbucket also learned this the hard way, and even made an April Fool's joke about it before realizing they had to primarily support git.

GitHub being centralized is a feature, not a bug. You don't have issues that exist in some people's repositories and not others. You don't have a question of who has the authoritative repository; either GitHub does, or GitHub doesn't and there's a note saying it's not authoritative. You can support things like have cross-site forks, but it's actively good for UX to have a single authoritative server for the current state of the project. (And you certainly don't want to require cross-site forks, since that would make it far more burdensome to submit a single patch.)

Re: Python moves to GitHub

#78
post #74

Earlier quoted context omitted.

What's the alternative? Everyone running their own little proprietary stacks with none of the features or community or ease of use?

Why would a free software project leave GitHub just to run a proprietary "stack"? You could try one of the self-hostable free software alternatives listed here: https://en.wikipedia.org/wiki/Comparison_of_source_code_host...

self-hostable and free doesn't mean they're not proprietary.

and my comment was more about the fact that github is just git (which is completely open) with some extra features. like the other comments have said, it's not really a big risk.

Re: Python moves to GitHub

#79

Earlier quoted context omitted.

Because of how Git is a distributed model, hosting your project on Github shouldn't be a big deal. You could host your project privately and then just have Github mirror that private host with hooks. Git being distributed means that you can host your project on as many different places as you want. And making the workflow to accept pull requests for Github, Gitlab, or other providers really isn't very difficult. They…

Because of how Git is a distributed model News flash: the number of people using the "D" in "DVCS" is so tiny that it might as well not be there. Central server with central authoritative repository, where all developers push and pull and synchronize, is how people use git in the real world, and it's time to stop pretending that any distributed features will ever be used. (which is to say, if github disappeared tomor…

I think that most open source projects just don't have the resources or contributor levels for true distributed development to happen.You probably are right that using a DVCS as intended is overkill for most projects.

But the whole reason why git exists at all is to support development of the Linux kernel. I don't think you can brush it off so easily.

Look here for an example of what real distributed development looks like with git: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next....

Re: Python moves to GitHub

#80
post #77
post #73

Earlier quoted context omitted.

Fossil [1] repositories include a distributed bug tracker (and also a distributed wiki and a distributed time-based notes system), and provides a browser-based UI. I've only read about it, not played with it, so don't know how close it comes to what you are envisioning. [1] http://fossil-scm.org/xfer/doc/trunk/www/index.wiki

It's a good idea! However, the distributed nature seems to make it sufficiently involved as to preclude a good UI (e.g., issues seem to use hashes), and the simple fact of not being git, regardless of whether it's better than git, is a serious problem for adoption. Bitbucket also learned this the hard way, and even made an April Fool's joke about it before realizing they had to primarily support git. GitHub being cen…

> and the simple fact of not being git, regardless of whether it's better than git, is a serious problem for adoption

I think I was a bit too terse. I didn't mean to suggest that someone who wanted to do everything (SCM, bug tracking) distributed use Fossil instead of git. The idea was to use git for the code, and Fossil for the bug tracking and wiki.

Post reply on HN