On Thu, 26 Dec 2019 at 01:43, Anatol Pomozov email@example.com wrote:
Thanks for the reply.
On Wed, Dec 25, 2019 at 2:20 PM Sven-Hendrik Haase firstname.lastname@example.org wrote:
I maintain the official gitlab packages gitlab, gitlab-gitaly, gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out
these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and gitlab-workhorse because they are way too much work to maintain and I
keep up and the result isn't great.
I remember discussions about using gitlab to manage our (future) git repos. If we want to go this route then we need to keep gitlab in our repos.
That is entirely orthogonal because we're using Docker for that
currently anyway as we'll use their Enterprise Edition offering which we didn't package.
I probably missed this discussion so I am out of context. But what is the reason we prefer Docker+EE versus using a plain Arch package for GitLab community edition?
Because Docker+EE works flawlessly and reliably while upstream breaks the packages we have every other release. Upstream _needs_ their Docker EE image to work as there's tons of money to be lost there but they don't care about our downstream packages. Also, I didn't see any way to package their EE at the time. I lost too much time maintaining these fruitless packages and it's time to cut those losses.