I'm not sure how the Docker devs handle non-AUFS-related contributions from contributors whose systems don't have AUFS (whether a failure on any tests means they refuse to consider patches, or whether they consider the tests relevant to the patch).
That's what I figured, and I'm glad to have it confirmed.
I've seen enough projects that have a rigid "if your dev environment isn't perfect, your code's no good to us" mindset that I was wary.
Also, just wanted to say that the Docker installation process and the rest of the Docker docs have been amazing. Originally, I was looking at writing a quick guide on getting up and running with Docker on Linode, but we decided linking the official docs made more sense considering how comprehensive they are.
That's awesome to hear! If you have any feedback on the documentation or would like to see other material please reach out to me: james.turnbull@docker.com. Or log a ticket and cc me on GitHub: jamtur01.
All storage drivers are unit-tested, but our integration tests (./integration/ in the repo) are currently tied to a specific host environment: namely, ubuntu 12.04 with an aufs-patched 3.8 kernel, version 0.8 of the lxc scripts, etc).
We are working on upgrading the integration test harness to handle a wider matrix of target systems, including those that don't handle aufs.
If you are interested in helping us out on this, come say hi on #docker-dev on freenode :) We are always looking for help and love to get new contributors and maintainers up and running.
Docker integration tests should not fail on an ubuntu system with all the dependencies installed (ubuntu-standard 3.8 kernel, lxc version 0.8, tar, git..), and when using the correct build environment (see http://docs.docker.io/en/latest/contributing/devenvironment/)
If tests still fail for you would you mind filing an issue? Thanks!
It appears to have a very unhappy time, primarily because the memory cgroup is not enabled. That was a deliberate choice because from what I can see there is a performance hit for enabling that (as well as the swap cgroup), and we decided to leave that disabled rather than give all users a performance hit in order to benefit docker users.
https://gist.github.com/akerl/8245192
I'm not sure how the Docker devs handle non-AUFS-related contributions from contributors whose systems don't have AUFS (whether a failure on any tests means they refuse to consider patches, or whether they consider the tests relevant to the patch).