LWN: Comments on "Moving some of Python to GitHub?"

Moving some of Python to GitHub?

smurf — Sat, 02 Jan 2016 14:28:38 +0000

No,. email is not a perfectly acceptable method for submitting a pull request. Not when compared to the time-saving (and mistake-preventing) things github does with a pull request, such as telling me whether there'd be a merge conflict or running Travis CI checks on it.

Non-controversial change / bug fix? three clicks and I'm done. Do that with a patch / git repository link in email.

Moving some of Python to GitHub?

thestinger — Fri, 12 Dec 2014 18:02:07 +0000

> Firefox -> Chrome

Chrome is nothing more than a branded build of Chromium with bundled Flash and EME plugins. Firefox isn't free software because the branding isn't free - just like Chrome. The only difference is that there's a restrictive set of terms under which you can use the Firefox branding with your own build.

There's a reason that Debian ships Firefox as Iceweasel but Chromium doesn't need to be altered.

So The One Aspect That Is Not In Dispute...

mchapman — Wed, 10 Dec 2014 08:01:24 +0000

> This seems to have been fixed since you last looked (I remember such behaviors). The old commits are now collapsed as "older diffs" which can be expanded to see the comments.

If that's the case, then it certainly has improved!

> The biggest issue is with deleting entire repos.

Yeah, I hit that one too. As I said before, I'm an "ad-hoc contributor" to many projects, which means I am very likely to remove a forked repository as soon as my branch has been merged. At the same time, though, I don't want the comments on the pull request to become lost to future contributors.

So The One Aspect That Is Not In Dispute...

mathstuf — Wed, 10 Dec 2014 04:13:59 +0000

> As far as I know, all of them allow posting without subscription, and they're mostly unmoderated. Spam has almost always never been a problem.

I maintain one low traffic list. You'd be surprised at the amount of spam that gets trapped in there.

> GitHub's workflow breaks completely when you rebase branches.

I rebase all the time and haven't had issues? It's better than email here because I have to look for all the old threads to see what was said about it before. I've also used other tools *cough*gerrit*cough* which do handle rebases very poorly and either email or GitHub is vastly preferable.

So The One Aspect That Is Not In Dispute...

mathstuf — Wed, 10 Dec 2014 04:09:41 +0000

> the pull request loses all of its comments.

This seems to have been fixed since you last looked (I remember such behaviors). The old commits are now collapsed as "older diffs" which can be expanded to see the comments. The biggest issue is with deleting entire repos.

Moving some of Python to GitHub?

fb — Wed, 10 Dec 2014 00:17:42 +0000

When I created my paid account at GitHub, there was only mercurial at bitbucket. Never heard about Gitlab, will check it out for curiosity's sake.

So The One Aspect That Is Not In Dispute...

MrWim — Tue, 09 Dec 2014 22:31:01 +0000

GitHub's workflow breaks completely when you rebase branches.

This used to annoy me too. It turns out you can make comments on changes which are bound to the pull-request rather than the commit. This means that they will be preserved even if you rebase and force-push. For an example see "Show outdated diff" on stb-tester pull-request 220. The trick is to click on "Files changed" at the top of the pull-request to make your comments rather than making the comments on the individual commits.

It's not perfect by any means. You still lose much of the history of the changesets but at least the review comments are preserved.

So The One Aspect That Is Not In Dispute...

fb — Tue, 09 Dec 2014 16:35:19 +0000

> I'm subscribed to a number of projects' mailing lists. As far as I know, all of them allow posting without subscription, and they're mostly unmoderated. Spam has almost always never been a problem.

I expect that posting spam to web pages is a different kind of spam than posting spam to mailing lists.

I imagine that one gets more spam when the end result is having your spam text getting hosted at some high profile web page. Mailing list archives are not as high profile.

At least the zsh-wiki used to get a lot of spam (years ago when I was an active visitor/contributor).

> GitHub's workflow breaks completely when you rebase branches.

(don't get me wrong, I like using rebase and use it *all the time*)

Most git users I know are scared to death of doing a rebase and won't touch or use it at all.

In general, I think code review at GH has a lot to improve. I also use code-collab at work, much better in some areas. GH doesn't have enough features while code-collab has too many features....

I'm still waiting for a (web) code review tool that is both powerful and easy to use.

Moving some of Python to GitHub?

fb — Tue, 09 Dec 2014 16:25:28 +0000

> So set a blog up and post copies of those requests there...

Seriously, who has the time and willingness to set up a blog and manage the publication of requests in it?

> What's so special about github pull requests?

They work.

Without a fuss or without the need for a project owner to set up anything more than a git repository. No need to setup blog or worry about how to publish, store and backup anything etc.

It takes 1 piece of information to fork and send pull requests. A project at GH. Sending stuff to mailing lists often requires creating an account first, and finding the aforementioned mailing list before that. So a PR is just a way to contribute that has a much lower barrier to entry for someone already on GH.

So The One Aspect That Is Not In Dispute...

mchapman — Tue, 09 Dec 2014 15:04:09 +0000

> Can you imagine the amount of spam people would get if you could just post/upload without an account?

I'm subscribed to a number of projects' mailing lists. As far as I know, all of them allow posting without subscription, and they're mostly unmoderated. Spam has almost always never been a problem.

> I understand that many are used to this workflow, my impression is that most projects today are using web interfaces to manage PRs etc. So I think this is more about one workflow losing relative popularity to another.

Actually, I'm quite happy with the issue stuff being on the web. That's the case with most projects, even those not using GitHub, and there's just as much lock-in with all the other solutions.

No, I find the bigger problems are with pull-request based workflow that GitHub uses -- specifically, how that workflow interacts with code review. If your branch is reviewed and it needs modifications, then these modifications *should* be made to the original commits (not just tacked on as extra commits), which necessarily means the branch will be rebased. GitHub's workflow breaks completely when you rebase branches.

So The One Aspect That Is Not In Dispute...

mchapman — Tue, 09 Dec 2014 14:47:43 +0000

> No one prevents you (or any other project hosted on github) from keeping that workflow. Even if someone submits a github-based pull request you can still do all the necessary steps without github (add the remote, pull, compare diffs/view logs, merge, push). Here github doesn't replace existing functionality but extends it.

No, but it's an impediment to me as an ad-hoc contributor to *other people's* projects.

With an email-based workflow, I can clone a repository, patch it, then git-send-email to the appropriate mailing list. In most cases, I don't even need to be subscribed to that list.

With a GitHub pull-request-based workflow I need a GitHub account (I've been resisting getting one for myself), I need to make sure I explicitly "fork" the repository within GitHub (simply pushing my copy of the repo to my account won't make pull requests work, as far as I know, because GitHub doesn't know that the original project and my project are "linked"), and I need to use the GitHub web interface to actually generate the pull request and take part in its review. If all of this isn't vendor lock-in, I don't know what is.

I've got bigger problems with the GitHub pull request workflow anyway. If you generate a pull request, discover that changes need to be made, you have two choices: you can create a new pull request, losing all comments from the previous one, or you have to add new commits. If you drop the to-be-pulled branch from your repository and replace it with a different branch with the same name, the pull request loses all of its comments.

So The One Aspect That Is Not In Dispute...

fb — Tue, 09 Dec 2014 14:41:18 +0000

> I do believe the data is available through some APIs, however.

They have a pretty decent HTTP-based API, pulling out all metadata from a project is trivial if you are comfortable issuing GET/POST requests.

https://developer.github.com/v3/

> To submit a pull request, you must first have forked the repository properly into your own account.

Can you imagine the amount of spam people would get if you could just post/upload without an account?

> As someone who is used to interacting with Git-based projects through patches and code review conducted over email (with git-send-email, etc.), I find these aspects of GitHub to be rather problematic.

I understand that many are used to this workflow, my impression is that most projects today are using web interfaces to manage PRs etc. So I think this is more about one workflow losing relative popularity to another.

_That_ said, you _can_ create PRs using command line tools, and you can answer to review comments using email (it gets included in the code review at the web page). I reckon that since most people are using the web interface, using email for PR reviews/comments is not as fine tuned as it could be.

So The One Aspect That Is Not In Dispute...

mbunkus — Tue, 09 Dec 2014 14:33:56 +0000

> I do believe the data is available through some APIs, however.

That is correct. They have a HTTP+JSON-based API that allows retrieval of all issues (pull requests are issues on github) as well as the other way around (creation and modification of issues). See https://developer.github.com/v3/

Wiki pages are just one special branch of your repository; so there's no problem exporting those either.

No one prevents you (or any other project hosted on github) from keeping that workflow. Even if someone submits a github-based pull request you can still do all the necessary steps without github (add the remote, pull, compare diffs/view logs, merge, push). Here github doesn't replace existing functionality but extends it.

One feature that I don't think you can archive easily, though, is the »comment on arbitrary lines and patches«. On github you can view a diff and add comments directly beneath the line you're referring to. I quite like that feature as it combines the context with precisely pointing out what you have something to say about. I vastly prefer this over email. But like I said I don't know if there's a way to export that data somehow.

So The One Aspect That Is Not In Dispute...

mchapman — Tue, 09 Dec 2014 13:13:28 +0000

> There's nothing on github that's any sort of lock-in.

I would disagree with that.

Their "issues" and "pull requests" systems, amongst other features, are vendor lock-ins. You can't even raise an issue or submit a pull request without a GitHub account. To submit a pull request, you must first have forked the repository properly into your own account. For project owners, getting your data out of these systems and into others could be difficult. I do believe the data is available through some APIs, however.

As someone who is used to interacting with Git-based projects through patches and code review conducted over email (with git-send-email, etc.), I find these aspects of GitHub to be rather problematic.

I do admit these are compelling features for project owners though.

Moving some of Python to GitHub?

tialaramex — Tue, 09 Dec 2014 10:50:59 +0000

"If you use github (professionally), you need a fallback, preferably self-hosted"

Such as, for example, github. They sell a boxed product (though of course historically boxed product versions of such sites get deprecated when the owner decides they wanted to be in some other business altogether, e.g. Google, Sourceforge).

Interestingly the public vs non-public repo stuff is still there in the boxed product. If I don't log in to our github instance it will show me various repos owned by other groups in the company (that are presumably marked "public" even though the whole thing is inside a firewall) but not our projects, which are private.

Moving some of Python to GitHub?

palmer_eldritch — Tue, 09 Dec 2014 08:34:05 +0000

With bitbucket or gitlab.com you get unlimited private/public repositories. Gitlab is FOSS.
But you only get git hosting, not a coders social network.

So The One Aspect That Is Not In Dispute...

dlang — Tue, 09 Dec 2014 08:24:09 +0000

The network effect is more than just popularity, it's that the functionality of the network increases based on the number of people using it (or more precisely, based on the square of the number of people using it). This is based mostly on the fact that you can only communicate effectively with people on the same network.

File formats have a similar effect, as they affect who you can exchange files with, even over other networks.

There's nothing on github that's any sort of lock-in. GitHub is a good service and it deserves to be used because they offer a good service at a good value.

But that's not the "network effect"

The closest thing I've seen mentioned is people who only look on github for software, and will use old versions found there instead of newer versions hosted elsewhere. I'm not really sure that qualifies as being such a strong draw.

Moving some of Python to GitHub?

ploxiln — Tue, 09 Dec 2014 07:12:42 +0000

It's not more stable. Around a dozen times a year, I run into timeouts fetching from github while deploying a revision of code to a set of servers. At my previous job, we had a backup synced repo to deploy from. I'm currently at a pre-launch startup, so we haven't set up such things yet, and it hit me today, for about an hour.

If you use github (professionally), you need a fallback, preferably self-hosted so you can better guarantee its uptime. (Same goes for chat clients like hipchat, which I've also experienced day-long outages of.)

So The One Aspect That Is Not In Dispute...

fb — Tue, 09 Dec 2014 06:04:56 +0000

> other than the name recognition, what causes this "network effect" you are talking about?

I got a paid account there for private personal projects because i. they sell private repo hosting for individuals (i.e. gitorious does not), ii. it was git, iii. the interface was good enough.

Then I change jobs and find myself as part of a project that wanted to move from SVN to Git, I was the only team member that had used git extensively before. Who drove the migration choices? I did ;-) Where did the team ended up? At GitHub.

So the trick with GitHub is: 1. they are popular, in fact the most popular DVCS host service; 2. their users are (for all I can tell) happy with what they get. So they have this huge net promotor score.

[...]

Their popularity also drives people into GitHub for the fact that it lowers the barrier to entry for new developers as -odds are- they should already be familiar with it.

Re: benefit from the network effects of GitHub

foom — Tue, 09 Dec 2014 02:19:39 +0000

If I want to find the source code of some package, so I can check what it's doing, or make some hack to it, or see when some behavior changed, how do I best do that?

Increasingly, the most useful answer is "search for it on github". Even when the project isn't actually hosted on github, a copy of their software is almost always there.

I used to use apt-get source, but, having the full VCS history is better.

I could use a general search engine, but that often just finds me the project's homepage. And finding a link to their favored git repository isn't always easy from there (Can you find python's VCS from www.python.org? I can't.). And sometimes, like python, they use the wrong VCS, "officially", so even if I could find such a link, it'd be useless.

So, that's why I always use github to find source code, these days.

If the project itself doesn't upload their own repo, perhaps I find an outdated clone someone else uploaded -- so, everyone really should at least keep an up-to-date mirror of their software on github, even if they don't use it for primary hosting.

Re: benefit from the network effects of GitHub

dlang — Tue, 09 Dec 2014 00:42:17 +0000

> Git makes it easy to pull from any number of places, and push to any number of places.

I agree, which is why this talk about the "network effects" of having it on github are confusing me.

Re: n favour of keeping Mercurial

ldo — Tue, 09 Dec 2014 00:29:19 +0000

I suspect that they found that the majority of contributors were in fact already using Git, interfacing to upstream Mercurial repos via git-remote-hg. So those clinging to Mercurial were starting to look somewhat ... isolated.

Also, Git ≠ GitHub; using the former doesn’t mean you have to use the latter.

Re: benefit from the network effects of GitHub

ldo — Tue, 09 Dec 2014 00:23:43 +0000

Network effects don’t have to be either/or: in fact, the more places you can find the code, the better.

For example, Linus Torvalds has a GitHub account, and puts a copy of the Linux kernel there. But nobody is suggesting that they get rid of git.kernel.org.

Git makes it easy to pull from any number of places, and push to any number of places.

So The One Aspect That Is Not In Dispute...

dlang — Mon, 08 Dec 2014 23:52:12 +0000

other than the name recognition, what causes this "network effect" you are talking about?

I've seen other projects migrate to GitHub with the proponents claiming huge benefits from the 'network effect' and the increased contributions that the project would get, only to see no change at all as a result of the migration.

I'm not opposed to using GitHub, they do offer a good service. But treating it like it's a social network or other proprietary system that isolates people from things not on GitHub just doesn't ring true to me.

So The One Aspect That Is Not In Dispute...

fb — Mon, 08 Dec 2014 23:14:10 +0000

> But the Blender folks manage to host their own development service just fine (at developer.blender.org)—is it that hard to do your own? That’s a project with a bit over a million lines of source code and perhaps around a hundred active developers. How big is Python?

The difficulty of hosting is not really a point if what you're after is just benefit from the network effects of GitHub.

A few years ago Red Hat's JBOSS/Wildfly migrated 'en masse' from IIRC self-hosted SVN repositories to GitHub. I don't think they were trying to save hosting costs...

Moving some of Python to GitHub?

fb — Mon, 08 Dec 2014 22:53:21 +0000

> There is an open alternative: gitorious.

I'm all for FOSS solutions. I wanted a remote Git repository provider that gave me *private* repositories. This is just to sync and backup some private stuff of my own.

Guess what? Gitorious is not interested in taking my money. Github OTOH will happily get paid to host my personal private repositories.

You can add that as another reason why they win out in the network effects.

Moving some of Python to GitHub?

mathstuf — Mon, 08 Dec 2014 18:11:05 +0000

Well, those certainly helped establish the network effects. I certainly wouldn't use it without the network effects at least (e.g., I already run my own cgit/gitolite setup at home).

So The One Aspect That Is Not In Dispute...

ber — Mon, 08 Dec 2014 16:25:27 +0000

There were arguments in favour of keeping Mercurial because it is written in Python (and slightly easier to learn and operate).

And one strong argument against Github is their locking-effect, with them running proprietary code.

Moving some of Python to GitHub?

ceplm — Sat, 06 Dec 2014 19:25:29 +0000

> vim/emacs/eclipse -> Sublime

I believe vim is still the most often used $EDITOR and I am not even sure Sublime is on the second post.

Distributed social networks can lead away from the trap

lamawithonel — Sat, 06 Dec 2014 18:33:05 +0000

This is what I was thinking. GitLab et al. really just need an open protocol/API for exchanging user metadata in conjunction with pull requests. All of GitHub's great features stem from the fact that it can track the network of users and pull requests. For example, their [network graph](https://github.com/blog/39-say-hello-to-the-network-graph...). The integration of ticketing helps, too.

So The One Aspect That Is Not In Dispute...

dlang — Sat, 06 Dec 2014 05:46:50 +0000

writing code and managing systems are different (but somewhat related) skillsets.

It's reasonable to say that they don't want to spend the resources to run the servers and just concentrate on the code.

that said, github is a reasonable place for your source, discussions and buglists, but you can't do thinks like host package repositories there (at least as far as I know)

So The One Aspect That Is Not In Dispute...

ldo — Sat, 06 Dec 2014 02:52:33 +0000

...is the move away from Mercurial towards Git. All the argument is over where to host the public Git repos and associated infrastructure.

But the Blender folks manage to host their own development service just fine (at developer.blender.org)—is it that hard to do your own? That’s a project with a bit over a million lines of source code and perhaps around a hundred active developers. How big is Python?

Moving some of Python to GitHub?

sadboy — Fri, 05 Dec 2014 22:00:58 +0000

> Well, I think the reason GitHub is big is because of network effects.

That, or it's just faster and more stable than its competitors.

Distributed social networks can lead away from the trap

pj — Thu, 04 Dec 2014 17:18:58 +0000

I keep hoping that mediagoblin will evolve into a good distributed social network.

Moving some of Python to GitHub?

gioele — Thu, 04 Dec 2014 13:04:55 +0000

> For whatever reason, the browser is now *the* interface. For us, it's mutt, gnus, etc. But for the next generation, it's the browser. I receive baffled looks when I speak of having to open a web browser.

> At least there finally is one GUI to rule them all. I suppose.

The browser is more a vt100 terminal or a X11 server. The "one GUI to rule them all" is yet to come: everybody who creates a web application these days has do recreate all its widgets or use a toolkit.

Distributed social networks can lead away from the trap

ber — Thu, 04 Dec 2014 10:06:07 +0000

In the mid term distributed social networks, funding and development functions are the way to avoid lock-in. The best technical approach I know for distributed social networking is http://pump.io. For distributed funding I think flattr's subscribe function is good and for development function we would need loose coupling of sites like sourceforge to enable cross dev-site requests.

To be fair on pump.io, it is in alpha. (My company runs a small beta service at https://io.intevation.de and we have an alpha bridge to other services at https://pumpbridge.me .) But it shows that the problem can be solved with resonable effort.

Moving some of Python to GitHub?

cebewee — Thu, 04 Dec 2014 06:34:26 +0000

It easily provides some public development infrastructure, even for projects small enough I wouldn't bother to set up blogs, mailing lists, issue tracker et al.

For example, Hackages has a lot of small Haskell libraries, often developed by a single person. Due to them being on Github, I have a standardized platform for communicating issues with the maintainer (I can even use mail to continue the discussion on their issue tracker). And this infrastructure comes basically for free with the repository -- no need to setup a separate mailing list or whatever is the preferred form of communication for you. Otherwise, most wouldn't bother and you are back to private communication with the maintainer.

Moving some of Python to GitHub?

pabs — Thu, 04 Dec 2014 06:07:19 +0000

The comment about shows how it doesn't matter as much as people think it matters. I can use git-hg to avoid having to learn Mercurial and Mercurial people have something similar IIRC.