Travis-CI auto-builds

Based on a suggestion from mwm, I figured I'd try to setup automated Deviation builds using Travis-CI. It turns out this is incredibly easy to do.

There is one downside which is that we need to switch from Bitbucket to GitHub. For now for testing I've cloned the repo here:
github.com/PhracturedBlue/deviation

It is already building the devo8 and devo10 and devo7e on Travis-CI. This was more of a proof of concept than anything else, but I was amazed how easy it was to do. It is stilla bit kludgey, re-downloading and installing the build environment for each build and each target. There is probably a way to prevent that

I am willing to make this move quickly if all developers are on board. We probably want to setup a github organization for shared ownership, and I'm not sure what else will be needed (for instance I don't know how to make the builds available after they build)

But it is pretty cool:
travis-ci.org/PhracturedBlue/deviation

the question will be more where do we put them (I like having builds available locally on the site), how do I do that securely, how often do we upload them (and how do we control that) and how many do we keep. We'll figure something out if we move in this direction

One issue is that our build system requires a cross-compiler which may limit the ability to run CI on any platform we may like.
There are a few CI options for bitbucket.

shippable appears very similar to Travis and supports bit-bucket. The free version doesn't support parallel runs, and I don't know how well supported it is. It seems to be docker enabled, so this may be an easy way to get the build running

drone.io may be too simple to meet our needs

wercker - I can't really tell, it seems like it is also docker enabled, so a build is probably possible. there isn't much available on what you get for $0 though

If we suck it up and move to git and github, users could continue to work on bitbucket I believe (since they support both VCS), with the benefits of private repos and what-not, and just issue pull requests to the github repo. you still get saddled with git, but the honest truth is that Hg is becoming more and more of a niche market. I may prefer Hg personally, but almost everyone else uses git and maybe we should too.

Except for goebish, that represents input from all the major (recent) contributors. Despite everyone being un-enthusiastic, I didn't here anyone who was going to start screaming if we switch to GitHub. I looked into it more, and it is possible to track a bitbukcet git repo against github, but s probably more trouble than it is worth. I'll let this simmer for a while, but it is looking more like this will be an overall win to transition (I'm assigning the value of CI a pretty high weight). Git has slightly different branching heuristics than Mercurial, and I'm not sure if we should keep all of the legacy branches during the migration, or prune everything to just the trunk, and keep the old Hg repo for historical purposes.

Goebish (or anyone else), if you want your say, please voice it. There is no immediate rush to this, but at the same reason, no reason to delay indefinitely.

I don't think I'm interested in considering anything other than a transition to Git (or nothing at all). I have found that being on a less-popular solution (be it hg vs git, bitbucket vs github, Kunena vs phpBB/vBulletin) can make it more difficult to find pre-boxed solutions to problems. I'm not unhappy with the decisions that have been made (and I have no reason to drop Joomla/Kunena), but if I'm going to make a change, I probably want to use the most-popular version whenever possible.