[aur-general] Dropping official gitlab packages

[Anatol Pomozov]

Hi

On Fri, Dec 27, 2019 at 4:19 AM Sven-Hendrik Haase <svenstaro at gmail.com> wrote:
>
>
>
> 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.

Got it.

Sven-Hendrik, I am actually interested to learn more about gitlab
product and its internals. I see that our package uses the old version
of ruby. Updating the package to ruby-2.6/2.7 and fixing some of the
bugs you mentioned will be a great opportunity for me to learn gitlab
and help community at the same time.

But as we do not plan to use this package at out site then I do not
want to invest too much time into it. What do you think if I take the
ownership over the packages you mentioned then port it to newer ruby
and later (around spring 2020) drop it to AUR?