Thanks @fredsmith for these detailed information! This confirms my impression: that edx.org and the rest of the community might have different deployment strategies, but they are reconcilable. I want to provide good defaults for most Tutor users, but I also want to enable more advanced users to replace some of the pieces of the deployment strategy by their own – like you do with edx.org. So in the end Tutor might not be a 100% good fit for edx.org, but I aim to make it a good starting point for system administrators who need both a scalable and easy-to-administer Open edX platform.
As I mentioned elsewhere, in my opinion, three things are missing for Tutor to be a good replacement for the native installation:
- A “bleeding edge” working deployment of the master branches.
- A clear transition path from the current native installation.
- Passing unit tests from inside the Tutor Docker images.
All three items are on the roadmap.
It was discussed in the last contributors’ meetup whether the group that decides on the future of the community installation should be part of the BTR working group. I think this project falls squarely within the attributions of the working group. It makes little sense to dissociate the release process and the testing of the actual release installation (IMHO). So we can discuss the progress of the “community installation v2 task force” (that’s a mouthful) during the weekly BTR meetups.
@arbrandes Please don’t hesitate to get in touch if you have any question about Tutor – but you know that already, right? 