move github repo under elixir-lang

[chulkilee]

I found erlang image is under the official erlang org (https://github.com/erlang/docker-erlang-otp)

Then.. what about moving this official docker repo under https://github.com/elixir-lang ?

[c0b]

I found erlang image is under the official erlang org (https://github.com/erlang/docker-erlang-otp)

that wasn't automatically happening but was transferred in c0b/docker-erlang-otp#38

I agree with your proposal if some maintainer at @elixir-lang side also agree, I can transfer this repo as well

[chulkilee]

Thanks - I posted it to elixirforum: https://elixirforum.com/t/call-for-proposals-time-zone-support-in-elixir/14743 to let @elixir-lang owners know..

Edit: https://elixirforum.com/t/moving-github-repo-of-the-official-docker-image-to-elixir-lang-org/14807

[gmile]

@chulkilee should the link be this instead? https://elixirforum.com/t/moving-github-repo-of-the-official-docker-image-to-elixir-lang-org/14807

[chulkilee]

@gmile you're right!

[chulkilee]

It turns out that there are three patterns of "official docker images"

• A. Official docker namespace, docker-library github repo
  • Python: _/python from https://github.com/docker-library/python
• B. Official docker namespace, own git repo
  • Sentry: _/sentry from https://github.com/getsentry/docker-sentry
• C. Own docker namespace, own git repo
  • Jenkins: jenkins/jenkins from https://github.com/jenkinsci/docker/

@c0b I guess you worked with Docker (or Docker community) for integration between the docker official image and this repository. Do you by any chance know what's common or preferred way for this?

[c0b]

https://github.com/docker-library/official-images#maintainership

read more in the Official Images README, I believe the preference is to be maintained by Upstream, but in reality there are many cases upstream has no interest of Docker, like Erlang has more than 20 years history with many other ways of deployment, not necessarily to have docker to deploy anything ; Elixir is similar has deployment solutions without docker; The Docker is only a popular way to deploy software but never be the only way, but as I see Docker / Kubernetes / Container is still gaining more popularity, it is possible that some day it becomes a de-facto only way and each of the software upstream will feel more interest / responsibility to support Docker officially

I am working in a company where using Erlang / Elixir a lot, but maintaining both of these official docker images for Erlang / Elixir more on my spare time, back in 2015 when there were no official images yet I asked the same question on Erlang / Elixir mailing list, seemed no enough interest at that time so I started from my personal namespace and it works well since then ; So if now the upstream shows up interest, I am ok to transfer it over, if not I am also ok to continue this model in another 5 or 10 years I am not retiring any time soon.

A. Official docker namespace, docker-library github repo

these were from Docker Inc to bootstrap their Docker Hub business, they've done the most popular choices in each of the Domain: the Programming Languages, the DB, the OS, may have top10 or top20 in each of the category, but this company sponsor'ed effort isn't limitless they're not doing all images

Once the Docker Hub business has bootstrapped since 2013-2015, I don't think Docker Inc is taking more responsibilities but more relying on 3rd party and community effort , and they're not dropping support either, if a PL / DB / OS upstream is not willing / has no interest to take over the official docker image maintenance, then it's Docker Inc continuing the responsibility

B. Official docker namespace, own git repo

the Sentry is a company maintaining their official docker images mainly for their business, so nothing special

C. Own docker namespace, own git repo

I believe the Jenkins is more of a community effort of maintaining open source software (or I am not sure if backed by some large companies)

If you consider category B and C are similar actually, main purpose is to promote their main product, by making it developer friendly, and those are strategies by Docker Inc the preferred way each software's Docker Image maintained by its upstream