[aur-general] Dropping official gitlab packages

[Santiago Torres-Arias]

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 <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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20191227/630d2053/attachment.sig>