Hi On Fri, Dec 27, 2019 at 4:19 AM Sven-Hendrik Haase <[email protected]> wrote: > > > > On Fri, Dec 27, 2019, 09:26 Anatol Pomozov <[email protected]> wrote: >> >> Hello Sven-Hendrik >> >> On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase <[email protected]> >> wrote: >> > On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer <[email protected]> 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?
