There is sustained interest in offering containerized versions of OpenRefine, in various forms:
- a Docker container (there are plenty of alternatives out there, Dockerized deployment · Issue #3986 · OpenRefine/OpenRefine · GitHub lists a few)
- a Snap package (https://github.com/OpenRefine/OpenRefine/pull/4484)
- Flatpak (Flatpak package for Linux · Issue #5533 · OpenRefine/OpenRefine · GitHub)
- AppImage
- maybe others I am not aware of?
While we could add the configuration files to generate those containers in the official repository, I think it could be simpler to have separate repositori(es) for that. It's a fairly common practice for larger projects where the people maintaining those packages are not necessarily the same as those maintaining the core software (see for instance GitHub - nextcloud/docker: ⛴ Docker image of Nextcloud or GitHub - wmde/wikibase-release-pipeline).
Would it make sense to have a new repository, say "OpenRefine/containers", which would host the configuration files for all those packages? Things like Dockerfile, the .snap directory, and other things like that. Or would you prefer to have one repository for each format? Intuitively, if we have a single repository then we could include a script to bump the version numbers in all scripts in one go, which would be quite useful when we publish releases.
My goal with having a repository in the organization to host those containers would be to give visibility to this packaging work currently done outside the scope of the project. We would invite the people maintaining those distributions to do so in this new repository. The distributions would become more trusted as they would be coming from the official project.
Let me know what you think!