[aur-general] Dropping official gitlab packages

[Sven-Hendrik Haase]

On Fri, Dec 27, 2019, 09:26 Anatol Pomozov <anatol.pomozov at gmail.com> wrote:

> Hello Sven-Hendrik
>
> On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase <svenstaro at gmail.com>
> wrote:
> > On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer <seblu at seblu.net>
> wrote:
> >>
> >> On Thu, 2019-12-26 at 01:51 +0100, Sven-Hendrik Haase via aur-general
> wrote:
> >> > On Thu, 26 Dec 2019 at 01:43, Anatol Pomozov <
> >> > 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.
> >>
> >> Hello,
> >>
> >> Both Docker images work flawlessly since years (they are officially
> supported).
> >> I guess the question was more about EE vs CE.
> >> I recently noticed than well known opensource distro now use the CE.
> >>
> >> Regards,
> >>
> >> Sébastien "Seblu" Luttringer
> >
> > Let's not go further in this direction please. This thread is about
> dropping/passing on maintenance of the gitlab packages. Hopefully some
> other TU can show these packages some love.
>
> I think that the question of maintaining 'gitlab' package in
> [community] is relevant to our future plans. If we want to go with
> gitlab to manage our repos then I propose to use the Arch package
> instead of a Docker image. The advantage of using the Arch package is:
>  - we show that we trust our own packaging abilities
>  - we put ourselves into our user's shoes. Using 'gitlab' package at
> our server will help us understand how other users deal with such
> systems. What are their pain points. Maybe it will force us to rethink
> how do we manage ruby releases or maybe we come up with better bundler
> integration or something else.
>
> So we need to decide whether we want to use the Arch package or the
> docker image. If Arch package is the preferable option then it should
> stay in the repo.
>

The whole point of this is that we don't trust our gitlab packages. I
wouldn't build our arch code hosting on those packages from what I've seen
in the past. In fact, even if those packages found a maintainer again, I'd
be opposed to actually using them ourselves in the short term.

One example of why I don't trust them: sometimes gitlab tags a security
release which would in theory need to be released quickly but then fails to
build so it stays vulnerable for a few days until I can get the build
fixed. This doesn't happen with the docker images.

I think the docker image is by far the preferable option for the time being.

>