Become self-hosted?

[jdpage]

This is, admittedly, a sort of meta-issue for all of my projects, not just w.pl, but I'm putting it here because if w.pl moves, I'll move everything.

There's rumblings in the FOSS community about a mass exodus from GitHub. Personally, I'm in favor for philosophical reasons.

In any case, the question of moving has the following points:

• Are there good reasons to stay? Would a mirror repo satisfy those reasons?
• Select a version control system: Mercurial, Fossil (probably not Git)
• Select a bug tracker: Mantis, Fossil
• New continuous integration (heartofgold? A new server entirely? Something hosted? Github mirror + Travis?)

[jdpage]

@woodrowbarlow

[woodrowbarlow]

i'm in favor of staying. your issue with github (as i understand it) is that it's a single point of failure for the open source community, but mirroring projects on multiple sources is the obvious solution.

advantages to staying:

• people can find our project more easily on github than elsewhere
• people trust github and already know how to use it
• github's issue tracker is pretty nifty (i like the lightweight versus powerful balance)
• the web interface has some powerful statistics tools and novel ways of viewing diffs etc.

advantages to leaving:

• if github does stuff we don't like we don't have to worry about it

unless you know something i don't, github really hasn't done anything to incite an exodus besides being good enough at what they do that a lot of people depend on them. if that changes, i would reconsider staying. until then, i don't see a reason to do more than set up an offsite mirror.

also, what's wrong with git? i'm not crazy about learning the quirks of a new vcs when git is still the industry standard.

anyway, that's my opinion. this is almost entirely your project, so it's your decision.

[jdpage]

Right now I'm basically leaning towards staying here, because moving is a lot of effort, but I would like to take a moment to take issue with your statement that "git is ... the industry standard". I would maintain that there is no such thing. A lot of projects are still on Subversion; in the Windows world, TFS and Vault are very common. Firefox and most other Mozilla projects are on Mercurial, along with Octave, GMP, OpenJDK, and Nginx, to name a few.

Github just happens to be the most high-visibility place for anybody who writes more than six lines of code to upload it, therefore Git (which, of all of the aforementioned VCSes, is the most quirky) gets the most coverage in the form of rage/crappy tutorials/panicked StackOverflow questions.

(Yeah, I said it: TFS is less quirky than Git. TFS is a stupid VCS, and definitely buggier than Git, but its conceptual model is very simple, and its interface is therefore very straightforward and it's a lot harder to destructively screw up.)

[woodrowbarlow]

i mean, we both have a decent understanding of how git operates under-the-hood and, with that knowledge, the paradigm really isn't that weird.

[jdpage]

In answer to what's wrong with Git:

• Git is based on an awfully clever idea: let's take a distributed data store, and build a version control system on top of it. This would be fine -- after all, it's what every VCS does to an extent -- except for the fact that to know how to do things in Git, you have to be very aware of both of these things, while other VCSes are quite good at abstracting it away.
  • e.g. TFS is based on a SQL database. I literally used it every day for months before finding this out; I only found out because someone mentioned that the SQL database in question needed to be moved to a bigger disk; and since then this knowledge has been of no use to me whatsoever, because how TFS actually goes about storing my files has never been an issue
  • e.g. I have no idea what Mercurial does in the background. All I know is that if I put my files into Mercurial, I get to work with the same VCS-level conceptual model as Git, with all of the advantages thereof, and I never have to hear the word "index" or understand what that means to avoid my code getting eaten.
• Git workflows -- oh lord, there are multiple ones -- tend to be based around the idea of a linear commit history, and rewriting history (often in the form of rebasing, commit squashing, etc.). Rewriting history is a fool's game, in my opinion, but if you don't go along with it, you're left with a nonlinear commit history, and the standard tooling just assumes that you have a linear history and interleaves them. W T actual F.
  • The whole "linearity" thing is actually the same thing I fault TFS/Vault/SVN for. When multiple people are editing source code, ephemeral branches are a fact of life, and sticking your head in the sand over it is not going to make anyone's day easier.
• You can lose branches to GC if they're not bookmarked. True story.
• There are commands in Git that change past commits. This is (a) stupid, and (b) terrifying. I say this coming from Mercurial-land, where by default the only way to change a commit is to run "rollback", and that only works on the last commit, and only as long as you haven't pushed it or cloned or edited any files in your working directory.
  • Yeah, Mercurial does have a history-rewriting extension, but you have to explicitly enable it to indicate that you're a chump who doesn't value his or her time or source code.
• Git on Windows and autocrlf. This feature and whoever thought it was a good idea should be banned from programming forever. It's like if someone tried to come up with a feature that automatically converted between tabs and spaces; in the short term, all it does is save someone the six seconds it takes to properly configure their editor, and in the long term, it's going to ruin someone's day entirely.
  • Yes, Mercurial also has this feature: as an extension, which you have to enable manually after reading documentation which basically says "DON'T USE THIS" at the top.

In conclusion,

[jdpage]

Git is basically the C++ of version control systems.