Moses, we have the problem, that most windows user, that install git via he official installer will opt for the (recommended) option that files are checked out with CRLF. I have the gut feeling, that if they have done so, bindmounting those files will produce non understandable errors in the outside layers of their stack for them. This would be another argument for having the git proxy and working over a network on the docker filesystem. Or we populate respective sources into bindmounted directories AFTER the startup in the run script... I mean to be able to leverage docker volume and OS standard tooling instead of having to especially prepare the IDE. And keep that stuff out of the odoo environment.

What I want to achieve is a standard way for new contributors to get coding quickly, weather they be on windows, osx or linux. My role model newcomer does not know python, nor git, nor does he know other stuff. He knows barely some basic concepts of the command line, and still he is valuable, because he might be able to copy paste some code and get his business case working. And, he might grow and evolve...

Installing python is cumbersome and litters your computer, and after you do a computer reset (I do that every 2 months probably) you have to start again setting everything up. Setup virtualenv is even more cumbersome, actually I never got a hold on it. So be python based solution discarted. We need binaries to get people going. Enter docker, it ships binaries. But I'm not getting at deploying. I'm aiming at the perfect, most cross platform, easy, dead simple, get going in less than 5 seconds development stack.

The point in the above mail is derived from Moses's (i feel) briliant idea to reuse the maintainance work, that is already present in the travis files. He wrote a tool, that transforms it into a buildable docker file (https://github.com/vauxoo/travis2docker). This set's up a complete environment (python deps, odoo deps other deps). So if you want to start hacking on some oca repo, you just have to clone it and build the automatically maintained dockerfile which includes the specific environment of this specific repo. And maintainers would carry on maintaining the travis files only, which have kind of the historic precedence rights on their side.

After building and docker run, you can hapily modify the src on your host and everthing get's bindmounted or synced into the docker, so you go to localhost:8069 and see what you have done instantly (with pynitify and odoo autoreload).

That's the kind of instantaneousness I want to see, also on windows systems. And I have not mingled one single time with anything of the kind of virtualenv, pythondeps, git blabla, missed module dependencies. It's just something like git clone && docker build . && docker run. Required binaries: git, docker. That's all - available for nearly any thinkable of common platform. And you are good to go hacking on your working directory.

Not: This is quite agnostic of whatever (probably git based) upper continuous integration workflow you chose. But this is anyhow not a concern of the one how just wants to get his hands dirty.

I'm trying to collaboratively discuss the best design for such a tool and am committed to come up with a beta-worthy solution for testing. Maybe I need some help here and there, but with communities support, I think it's doable.

Hi David,
We appreciate your various contribution but in this case, I am not
sure to understand where you are getting at.
Docker is very nice environment and I am in favor for the deployment
although the techno is style young is not completely bullet proof.
We have our own here based on OCB and refreshed every week (as of
next week) : https://hub.docker.com/u/elicocorp/.
You can grab docker-files
here:https://github.com/Elico-Corp/odoo-docker
(I will send a separate mail anyway to check if community could be
interested in maintaining this repo in OCA)

But I dont see the point of your exercise. Current infrastructure is
solid for travis: once your code is solid and your docker file is
well structured, there is no need to travis the dockers (IMHO).

Resources are limited and we do not want to tumble our
infrastructure that we have needed month to stabilize so we need
clear objective and pros for the community and you will come with a
fully prepared solution.
We barely have resources for maintainance and cannot really just TRY
things...
If you can come with solid project definition and proof of concept +
some resources to maintain it in the community, we could consider it

Having talked with Moses (vauxoo) bilateral about
his solution further, I would like to gather support for the
following attempt (ATTEMPT = TEST = TRY = EXPERIMENT):

- Transform travis to use docker

- Run travis2docker (or a small modification of it) to
create DEV docker files in repo

- Start a dev environment with docker build . &&
docker run and easily mount the working tree into it's place

Best advantage: Binaries for almost every platform are
available in the docker ecosystem.

Manual maintenance can focus on the Travis files, the
rest is already scripted...

@Moses: when talking
about mounting instead of syncing via a network protocol
via the docker volume command (read: let the docker host
take care of this) we cannot AFAIK let the docker be the
source, because docker gives precedence to the host files
system and eventually deletes anything that was present in
this path on the docker itself. So we might have a closer
look on how we could include the git proxy workflow
nevertheless. It's important though, that a local git can
be easily referenced, so no internet connection is
needed...

It's WIP, but with your feedback, I'm commited
to make it 1.0 at the indicated detail level in no
time. I hope it might also trigger or revive
connected discussions, such as repo layout. (https://github.com/OCA/maintainer-tools/issues/147)
- For my taste, I invite you to discuss directly
on the github issue to not bother the less
involved.

I'll reference also a second mail to follow,
with a proposal for modernizing informal
communication with the help of gitter.im.