Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose moving official Elixir image builds here #245

Open
tsloughter opened this issue Sep 18, 2019 · 11 comments
Open

Propose moving official Elixir image builds here #245

tsloughter opened this issue Sep 18, 2019 · 11 comments

Comments

@tsloughter
Copy link
Contributor

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)

@c0b
Copy link
Collaborator

c0b commented Oct 23, 2019

is it a merge of current docker-elixir repo content to here, or a separate repo like https://github.com/erlang/docker-elixir ?

@tsloughter
Copy link
Contributor Author

I think merge into a single repo to be simpler.

@garazdawi
Copy link
Contributor

What is the advantage you see of moving them to the erlang organization?

@tsloughter
Copy link
Contributor Author

@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.

@garazdawi
Copy link
Contributor

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.

@tsloughter
Copy link
Contributor Author

Ok. We will talk about moving this repo there as well then.

@garazdawi
Copy link
Contributor

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?

@tsloughter
Copy link
Contributor Author

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.

@wojtekmach
Copy link

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.

@max-au
Copy link

max-au commented Oct 24, 2019

I actually like the idea of moving all BEAM flavours under one umbrella. Always wanted to have LFE Docker image.

@starbelly
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants