On Fri, Dec 27, 2019 at 01:19:08PM +0100, Sven-Hendrik Haase via aur-general 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.
I'm greatly behind the idea of dogfooding, but I understand the technical limitations and its practical scope. We may perhaps need to take on this beyond a packaging challenge but something we can pick up as a project... Have we been able to talk with upstream and air our concerns? maybe we could start a more closely-knit collaboration with them and improve the state of their build toolchain? Cheers, -Santiago
signature.asc
Description: PGP signature
