On Fri, Dec 27, 2019 at 4:19 AM Sven-Hendrik Haase firstname.lastname@example.org wrote:
On Fri, Dec 27, 2019, 09:26 Anatol Pomozov email@example.com wrote:
On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase firstname.lastname@example.org wrote:
On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer email@example.com 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.
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.
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.
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?