Re: [aur-general] Dropping official gitlab packages

2019-12-27 Thread Sven-Hendrik Haase via aur-general
On Fri, Dec 27, 2019, 23:41 Anatol Pomozov  wrote:

> Hi
>
> Per discussion with Sven-Hendrik I am going to become maintainer for
> these packages.
>
> Aaand the first batch of changes (switching gitlab to ruby 2.6) has
> landed [community-testing]. Please give it a try and send feedback if
> you see any issues.
>

Thanks a lot! Good to see these going to a loving home. Don't forget to
assign yourself all the bugs.

>


Re: [aur-general] Dropping official gitlab packages

2019-12-27 Thread Anatol Pomozov via aur-general
Hi

Per discussion with Sven-Hendrik I am going to become maintainer for
these packages.

Aaand the first batch of changes (switching gitlab to ruby 2.6) has
landed [community-testing]. Please give it a try and send feedback if
you see any issues.


Re: [aur-general] Dropping official gitlab packages

2019-12-27 Thread Anatol Pomozov via aur-general
Hi

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


Re: [aur-general] Dropping official gitlab packages

2019-12-27 Thread Santiago Torres-Arias via aur-general
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  wrote:
> 
> > Hello Sven-Hendrik
> >
> > On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase 
> > wrote:
> > > On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer 
> > 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


Re: [aur-general] Dropping official gitlab packages

2019-12-27 Thread Sven-Hendrik Haase via aur-general
On Fri, Dec 27, 2019, 09:26 Anatol Pomozov  wrote:

> Hello Sven-Hendrik
>
> On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase 
> wrote:
> > On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer 
> 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.

>


Re: [aur-general] Dropping official gitlab packages

2019-12-27 Thread Anatol Pomozov via aur-general
Hello Sven-Hendrik

On Thu, Dec 26, 2019 at 11:47 AM Sven-Hendrik Haase  wrote:
> On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer  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.


Re: [aur-general] Dropping official gitlab packages

2019-12-26 Thread Sven-Hendrik Haase via aur-general
On Thu, Dec 26, 2019, 18:14 Sébastien Luttringer  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.

>


Re: [aur-general] Dropping official gitlab packages

2019-12-26 Thread Sébastien Luttringer via aur-general
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



signature.asc
Description: This is a digitally signed message part


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Sven-Hendrik Haase via aur-general
On Thu, 26 Dec 2019 at 01:43, Anatol Pomozov 
wrote:

> Thanks for the reply.
>
> On Wed, Dec 25, 2019 at 2:20 PM Sven-Hendrik Haase 
> wrote:
> >> > I maintain the official gitlab packages gitlab, gitlab-gitaly,
> >> > gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out
> of
> >> > these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and
> >> > gitlab-workhorse because they are way too much work to maintain and I
> can't
> >> > keep up and the result isn't great.
> >>
> >> I remember discussions about using gitlab to manage our (future) git
> >> repos. If we want to go this route then we need to keep gitlab in our
> >> repos.
> >
> >
> > That is entirely orthogonal because we're using Docker for that
> currently anyway as we'll use their Enterprise Edition offering which we
> didn't package.
>
> I probably missed this discussion so I am out of context. But what is
> the reason we prefer Docker+EE versus using a plain Arch package for
> GitLab community edition?
>

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.


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Sven-Hendrik Haase via aur-general
On Wed, 25 Dec 2019 at 23:47, Giancarlo Razzolini 
wrote:

> Em dezembro 25, 2019 19:36 Karol Babioch via aur-general escreveu:
> >
> > Announcing this on main site as dedicated news entry is probably
> > overkill? At least it would get some attention and potentially some new
> > maintainer could be found this way ;-)?
> >
> > Not sure how many people are using those packages, but this is seriously
> > disruptive. Anyone running on this, would probably appreciate to be
> > aware of the situation ...
> >
>
> I think Sven should have used the arch-dev-public mail list, but it does
> not
> change the fact the current packages are hard to maintain and if no other
> developer
> or trusted user wants to pick it up, it will be dropped.
>

I thought aur-general for [community] and AUR and arch-dev-public for
[extra] and [core] discussion? This way, non-TU users will get a chance to
speak up here in case they want to aspire to be maintainers for the
packages to be dropped for when they land in AUR.


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Anatol Pomozov via aur-general
Thanks for the reply.

On Wed, Dec 25, 2019 at 2:20 PM Sven-Hendrik Haase  wrote:
>> > I maintain the official gitlab packages gitlab, gitlab-gitaly,
>> > gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out of
>> > these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and
>> > gitlab-workhorse because they are way too much work to maintain and I can't
>> > keep up and the result isn't great.
>>
>> I remember discussions about using gitlab to manage our (future) git
>> repos. If we want to go this route then we need to keep gitlab in our
>> repos.
>
>
> That is entirely orthogonal because we're using Docker for that currently 
> anyway as we'll use their Enterprise Edition offering which we didn't package.

I probably missed this discussion so I am out of context. But what is
the reason we prefer Docker+EE versus using a plain Arch package for
GitLab community edition?


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Giancarlo Razzolini via aur-general

Em dezembro 25, 2019 19:36 Karol Babioch via aur-general escreveu:


Announcing this on main site as dedicated news entry is probably
overkill? At least it would get some attention and potentially some new
maintainer could be found this way ;-)?

Not sure how many people are using those packages, but this is seriously
disruptive. Anyone running on this, would probably appreciate to be
aware of the situation ...



I think Sven should have used the arch-dev-public mail list, but it does not
change the fact the current packages are hard to maintain and if no other 
developer
or trusted user wants to pick it up, it will be dropped.

Now, dropping does not mean deleting, they'll be moved to the AUR by Sven and 
subsequently
orphaned, precisely to allow interested parties to pick it up and maintain it.

News items are for things that require user attention and/or manual 
intervention. The gitlab
package will continue working after it gets dropped, just won't be updated 
anymore until someone
wishes to maintain it on the AUR.

Regards,
Giancarlo Razzolini

pgptVN7cKYC6a.pgp
Description: PGP signature


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Eli Schwartz via aur-general
On 12/25/19 5:31 PM, Sven-Hendrik Haase via aur-general wrote:
> On Wed, 25 Dec 2019 at 23:30, Karol Babioch via aur-general <
> aur-general@archlinux.org> wrote:
> 
>> Hi,
>>
>> Am 25.12.19 um 23:18 schrieb Anatol Pomozov via aur-general:
>>> I remember discussions about using gitlab to manage our (future) git
>>> repos. If we want to go this route then we need to keep gitlab in our
>>> repos.
>>
>> So is the recommendation for anyone currently using the packaged version
>> to migrate to the Docker image?
>>
>> Maybe this can be communicated accordingly, when no other maintainer can
>> be found.
>>
>> Best regards,
>> Karol Babioch
>>
>>
> We don't really have any system for communication for things like that in
> place except for this mailing list. What other mechanism do you imagine?

I'd argue arch-dev-public moreso than aur-general...

-- 
Eli Schwartz
Bug Wrangler and Trusted User



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Karol Babioch via aur-general
Hi,

Am 25.12.19 um 23:31 schrieb Sven-Hendrik Haase:
> We don't really have any system for communication for things like that
> in place except for this mailing list. What other mechanism do you imagine?

Announcing this on main site as dedicated news entry is probably
overkill? At least it would get some attention and potentially some new
maintainer could be found this way ;-)?

Not sure how many people are using those packages, but this is seriously
disruptive. Anyone running on this, would probably appreciate to be
aware of the situation ...

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Sven-Hendrik Haase via aur-general
On Wed, 25 Dec 2019 at 23:30, Karol Babioch via aur-general <
aur-general@archlinux.org> wrote:

> Hi,
>
> Am 25.12.19 um 23:18 schrieb Anatol Pomozov via aur-general:
> > I remember discussions about using gitlab to manage our (future) git
> > repos. If we want to go this route then we need to keep gitlab in our
> > repos.
>
> So is the recommendation for anyone currently using the packaged version
> to migrate to the Docker image?
>
> Maybe this can be communicated accordingly, when no other maintainer can
> be found.
>
> Best regards,
> Karol Babioch
>
>
We don't really have any system for communication for things like that in
place except for this mailing list. What other mechanism do you imagine?


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Karol Babioch via aur-general
Hi,

Am 25.12.19 um 23:18 schrieb Anatol Pomozov via aur-general:
> I remember discussions about using gitlab to manage our (future) git
> repos. If we want to go this route then we need to keep gitlab in our
> repos.

So is the recommendation for anyone currently using the packaged version
to migrate to the Docker image?

Maybe this can be communicated accordingly, when no other maintainer can
be found.

Best regards,
Karol Babioch



signature.asc
Description: OpenPGP digital signature


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Sven-Hendrik Haase via aur-general
On Wed, 25 Dec 2019 at 23:18, Anatol Pomozov 
wrote:

> Hi
>
> On Tue, Dec 24, 2019 at 11:00 PM Sven-Hendrik Haase via aur-general
>  wrote:
> >
> > Hi guys,
> >
> > I maintain the official gitlab packages gitlab, gitlab-gitaly,
> > gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out of
> > these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and
> > gitlab-workhorse because they are way too much work to maintain and I
> can't
> > keep up and the result isn't great.
>
> I remember discussions about using gitlab to manage our (future) git
> repos. If we want to go this route then we need to keep gitlab in our
> repos.
>

That is entirely orthogonal because we're using Docker for that currently
anyway as we'll use their Enterprise Edition offering which we didn't
package.


Re: [aur-general] Dropping official gitlab packages

2019-12-25 Thread Anatol Pomozov via aur-general
Hi

On Tue, Dec 24, 2019 at 11:00 PM Sven-Hendrik Haase via aur-general
 wrote:
>
> Hi guys,
>
> I maintain the official gitlab packages gitlab, gitlab-gitaly,
> gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out of
> these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and
> gitlab-workhorse because they are way too much work to maintain and I can't
> keep up and the result isn't great.

I remember discussions about using gitlab to manage our (future) git
repos. If we want to go this route then we need to keep gitlab in our
repos.


[aur-general] Dropping official gitlab packages

2019-12-24 Thread Sven-Hendrik Haase via aur-general
Hi guys,

I maintain the official gitlab packages gitlab, gitlab-gitaly,
gitlab-runner, gitlab-shell, gitlab-workhorse and python-gitlab. Out of
these, I'll be dropping gitlab, gitlab-gitaly, gitlab-shell and
gitlab-workhorse because they are way too much work to maintain and I can't
keep up and the result isn't great.

Currently known bugs:
https://bugs.archlinux.org/task/62837
https://bugs.archlinux.org/task/63679
https://bugs.archlinux.org/task/63688
https://bugs.archlinux.org/task/63935
https://bugs.archlinux.org/task/63950
https://bugs.archlinux.org/task/64337
https://bugs.archlinux.org/task/64887

Unless any other masochistic TU really wants to feel the pain, I'll be
dropping them in about two weeks.

Sven