Fullstaq Ruby's long-term vision is to become healthy open source project that can run on its own, and that survives and thrives even without the active input of its founders.
We need to set up the appropriate documentation, systems and processes to allow easily accepting contributions. We need to think about team formations, on- and offboarding, triage processes, and more.
Miscellaneous polish is required to let the Server Edition enter General Availability status.
This is going to be a fork of the official Ruby images by Docker Inc. We'll integrate activatecontaineruid to encourage running as non-root.
Still need to figure out how this works. Maybe we need to fork the Ruby buildpack. Maybe we can even convince the Ruby buildpack maintainers to use our distribution by default.
Have a CI/CD pipeline so that we can fully automate the release process, and so that building is fast. Each release generates 70+ packages (in the future maybe 100+) this needs to be massively parallelized.
We currently host the DEB and RPM packages as files in the Github release system, but this is not very user friendly. We should have a proper APT and YUM repository from which users can download packages, and to which we can publish newly built packages.
Points of attention:
- Highly available, because users will depend on it for production installs.
- Integration with a CDN so that everybody can download quickly.
- Signed.
- We need to think about GPG key management.
- An HTTP API endpoint, used for publishing newly built packages.
- A future CI/CD pipeline can integrate with this.
- Must be authenticated.
- Must allow atomically publishing many packages at once.
- Retain older package versions.
- We need to think about backups and preventing accidental overwrites of older packages.
- The Passenger APT, YUM and generic binaries repositories used 5 TB/mo at its peak. If we assume that Fullstaq Ruby will become popular then we should keep this order of magnitude of traffic in mind.