Docker Reproducable Builds

Hi Evan,

I was reading #11 and had to laugh about the confusion. Anyhoo, I'm definitely in the right place and am talking about the right MESA (mesa.sourceforge.net)

The ultimate point made in #11 still holds - it's beneficial/important on many levels to have 100% reproducable builds in a docker image (which is why the Dockerfile concept even exists and what makes Docker so powerful -- with the same Dockerfile as the input, the finished container should be 100% identical for everyone ... each and every time... Which is amazing for testing - i.e. ensuring that your environment is 100% pristine and 100% consistent so that you don't have that fun situation of making a seemingly unrelated change to the OS and having your code break! :grin: )

The other major advantage is the way that Docker builds the container as intermediate layers - for the most part, each statement in a Dockerfile creates a new layer. If you change a statement midway through the file, Docker *re-uses* the parts above it that were already built - potentially making a rebuild significantly faster (depending on where your change is).

Essentially, the difference is: instead of starting a container, editing it (through say ```docker exec bash```), and saving it, you just put all of your "editing" commands into the Dockerfile - anything you need to run/edit/compile/etc. goes right in there. Which makes it 100% reproducable and much easier to fix/upgrade/edit.

Thoughts?

Start by reviewing the Dockerfile-related approach described here and the confusion referenced in issue #11. Check how the current image is built and whether the repository has documented build inputs or commands; done should mean the requested reproducible-build behavior is clearly defined and consistently demonstrated.

Written by the indexing model from the issue text.