Propose moving official Elixir image builds here
tsloughter opened this issue · comments
Thoughts on removing the need for https://github.com/c0b/docker-elixir/ by having them handled in this repo? While also expanding the support for OTP versions per Elixir version as brought up in this issue c0b/docker-elixir#122 (comment)
is it a merge of current docker-elixir repo content to here, or a separate repo like https://github.com/erlang/docker-elixir ?
I think merge into a single repo to be simpler.
What is the advantage you see of moving them to the erlang organization?
@garazdawi because this repo already exists it seemed like a simple way to end people's constant questions of, "who is @c0b and can I trust these images?" :). Another option would be for the build and packaging working group to take them under the ErlEf organization.
Another option would be for the build and packaging working group to take them under the ErlEf organization.
I like this idea more than putting the elixir images here.
If the ErlEf had existed when we moved this repo here, I probably would have suggested it be there as well.
Ok. We will talk about moving this repo there as well then.
Ok. We will talk about moving this repo there as well then.
Just to be clear. I was not suggesting that we move this repo to the ErlEF. All I said was that if it had existed back then, I think it would have been a good idea to have it there. Now that it is here, I would rather it remain so that we don't move things about without good reasons.
Unless there are administrative gains or other synergies to be had by having them in the same repo?
I think it is simpler for those working on it to have them in the same repo, especially since there is a new goal to provide Elixir images on all (I think, definitely at least more) Erlang releases.
Curious what others think, esp @c0b @getong @beardedeagle and @wojtekmach -- all of whom maintain Erlang and Elixir images separately and which we'd like to combine the efforts of.
I think having images for erlang, elixir, and hopefully other BEAM languages in the same org or repo speaks to that trust concern that @tsloughter mentioned and that sounds good to me.
Regarding whether there should be a repo per language or a monorepo with all supported languages, I'd say if there's any tooling that could be shared between these, monorepo would make it easier to maintain. On the flip side, if someone subscribes to such monorepo to be notified about, say, erlang docker issues, they'd be notified about elixir (and possibly lfe etc) issues too. If it would be up to me and in hindsight I'd have started with a monorepo and break it up later if that would be useful. Now that are existing repos per language, I'd probably only consider merging them together to share tooling (e.g. CI pipelines, build scripts etc) and/or enforce code organization.
I actually like the idea of moving all BEAM flavours under one umbrella. Always wanted to have LFE Docker image.
