From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B0CF4138334 for ; Thu, 14 Jun 2018 14:25:18 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3A2EBE0965; Thu, 14 Jun 2018 14:25:16 +0000 (UTC) Received: from mail-yw0-f195.google.com (mail-yw0-f195.google.com [209.85.161.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EA51BE0954 for ; Thu, 14 Jun 2018 14:25:15 +0000 (UTC) Received: by mail-yw0-f195.google.com with SMTP id b125-v6so2205911ywe.1 for ; Thu, 14 Jun 2018 07:25:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=/JPky6rKBqT8YdBZmiM+xSEyIvE9E57CtSF+c6QeKJE=; b=BkqKZW0Fx5zCqEsVYRcpOQ2FkpJwvGmZBO1Uzg5bfq5HjxgFlmQNVe2agRTrEA6tEk xOwIqm/RSy7AYtmmf07MnA6fUZQhkD89IIOSH47tuszy9083Qasx4HC22a3XuNV8EZJk 0mdbuv2CmVL3nKMYO896ZSANICi1S8lwZV2keQUYUKkX0UpQUyubj5g8kKGuOsbDmUdi 7HyXNtkP4uQ70TjS7doHZTiINKWFI24MbtetXCaxstA9mHWH2X9mzhrwVdD3i4xcBsE7 8WIZHmyOi00CPOP6j92/MQcqirONnMXZnrLCWu0Bl39HRoRe+xD5VK63SYh1c+i0uD4o URfQ== X-Gm-Message-State: APt69E13GCrFavGpUaZi4V3J7PYMJaYNEOUzJGSBH49VRRydustQQXPC Oarv8LdsSVvp1UZsO+/JD/dDnIqRnIysVvKVrvs= X-Google-Smtp-Source: ADUXVKITGubk/STQ4Qhoko6iAvfLTWDBLktIxzZAlGt2Jie8ya4A+sRFlj+5bRFD1bthQHGfmkw5B7JDJJn3L9IviXY= X-Received: by 2002:a81:a802:: with SMTP id f2-v6mr1482430ywh.136.1528986314636; Thu, 14 Jun 2018 07:25:14 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 References: <1528529135.1261.34.camel@gentoo.org> <23323.34479.67401.2943@a1i15.kph.uni-mainz.de> <1528530763.1261.36.camel@gentoo.org> <20180614104751.120ab2f3@red.yakaraplc.local> In-Reply-To: From: Mauricio Lima Pilla Date: Thu, 14 Jun 2018 11:25:03 -0300 Message-ID: Subject: Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub To: gentoo-project@lists.gentoo.org Content-Type: multipart/alternative; boundary="000000000000268394056e9ade08" X-Archives-Salt: 37615d60-d935-4a46-a23c-62333c3cb659 X-Archives-Hash: 0fdb0b109de6e476c99797d0bd5e1d4d --000000000000268394056e9ade08 Content-Type: text/plain; charset="UTF-8" Perspective of a Gitlab user: We use it for managing a small research lab. First I had it installed in a Ubuntu server, but recently -- an year ago -- I moved it to a Docker container. It seems to be very important to keep it up-to-date or at least go through intermediate versions to avoid breakages. That said, it seems to work pretty well even with the LDAP integration on. Even when I managed to break it in a upgrade, it was fairly easy to get it running again. If you are smarter than me, you would first make a snapshot of the container though. Shame on me for not keeping those more up-to-date with their releases. On Thu, Jun 14, 2018 at 11:15 AM Alec Warner wrote: > > > On Thu, Jun 14, 2018 at 5:47 AM, James Le Cuirot wrote: > >> On Mon, 11 Jun 2018 09:28:37 -0400 >> Rich Freeman wrote: >> >> > All that said, I haven't used the gitlab core functionality >> > personally, so I can't vouch for how it stands up on its own against >> > github. I might go deploy it in a container or something to try it >> > out. >> >> I used our own self-hosted instance at work. I think it is perfectly >> adequate. I haven't dug in but it seems to have quite a rich API so >> there's lots of potential. >> >> > My understanding is that the main barrier to having Gentoo infra host >> > gitlab is ruby - they don't like ruby (I don't know all the reasons - >> > they're probably good ones). If github.com is offering free hosting >> > that would be a way to get out of that problem. On the other hand, if >> > something bad does happen down the road, there is always the chance >> > that we'll have to move to self-hosting without a lot of warning, and >> > that means having to deal with ruby whether we like it or not (or lose >> > stuff like issues/PRs/etc that aren't in git itself). >> >> There are more than two options available here. >> >> There are various cloud options including Docker, Kubernetes, and >> OpenShift. I don't know much about that. >> >> GitLab's preferred method of installation is their Omnibus packages for >> various distributions but obviously not Gentoo. This is basically >> uber-bundling where they bundle just about everything including >> PostgreSQL. I have not tried this method. I don't know how feasible or >> even desirable it would be to try and use these. >> >> There is a Chef cookbook for installing the Omnibus packages but this >> is limited to the same set of distributions. >> >> There is also an unofficial Chef cookbook for installing "from source" >> that I currently maintain, somewhat minimally. Unfortunately it only >> supports RHEL (and derivatives) and Debian, and I only test on CentOS. >> Their own documentation for installing from source is fairly >> comprehensive but the cookbook gives a good indication of how you can >> script it up. >> >> https://github.com/atomic-penguin/cookbook-gitlab-deprecated >> >> When we say "from source", what we actually mean is that the various >> dependencies, apart from the Ruby gems and JavaScript libraries, are >> installed from distro packages where possible or from source when the >> packages are too old. This includes Ruby itself, Go, NodeJS, >> PostgreSQL, Redis, nginx, and obviously git. I expect Gentoo would have >> no trouble providing recent enough versions of these. You then clone >> the various GitLab repositories (currently 4, could be worse), build >> the Go code, and install further dependencies with Bundler and YARD, >> before doing some final setup tasks and firing it up. >> >> Using Bundler and YARD goes against Gentoo packaging but the list of >> dependencies for both sides is extremely long. I very much doubt we >> could keep on top of that and I understand this kind of pain because >> this is the same situation that the Java team finds itself in. At least >> in this case, there are most likely no pre-compiled binaries involved >> so the benefits of packaging are limited anyway. Ruby gems that include >> native code typically build from source on installation. >> >> I can't comment much about the JavaScript side but on the Ruby side, >> there are Gemfile.lock files present that lock the Ruby gem >> dependencies down to specific versions. If we did want to package the >> gems, we would probably not want to be tied to such specific versions. >> You could possibly delete these and fall back to the looser constraints >> in the Gemfiles but you may run into unexpected issues. You could argue >> that we may want to do this even if we don't package the gems in order >> to benefit from fixes (including security) but GitLab is very actively >> maintained and the lock files are frequently updated. >> >> Keep in mind that GitLab is a very fast-moving project. Security issues >> are frequently found but these are fixed quickly. This is not the sort >> of project we could install once and then maybe patch up just once a >> year or so. >> >> > They seem to offer docker packages, so we could just nab those and run > them in containers on hosts. I'm not too keen on doing a bunch of (really > what I consider busywork) to try to 'get it working on Gentoo.' We already > use upstream provided containers and I expect that to continue as upstreams > continue to abandon the 'release packages' model and move to 'release sets > of containers' model. > > -A > > >> I hope you found this informative! >> >> Regards, >> -- >> James Le Cuirot (chewi) >> Gentoo Linux Developer >> >> > -- Mauricio Lima Pilla, D.Sc. http://beagle.ufpel.edu.br/~pilla pilla@ufpel.edu.br, mauricio.pilla@gmail.com, pilla@gentoo.org "I'm just very selective about the reality I choose to accept." -- Calvin --000000000000268394056e9ade08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perspective of a Gitlab user:

We use it= for managing a small research lab. First I had it installed in a Ubuntu se= rver, but recently -- an year ago -- I moved it to a Docker container.=C2= =A0

It seems to be very important to keep it up-to= -date or at least go through intermediate versions to avoid breakages. That= said, it seems to work pretty well even with the LDAP integration on. Even= when I managed to break it in a upgrade, it was fairly easy to get it runn= ing again. If you are smarter than me, you would first make a snapshot of t= he container though.

Shame on me for not keeping t= hose more up-to-date with their releases.
=C2=A0


On Thu, Jun 14, 2018 at 11:15 AM Alec Warner <antarus@gentoo.org> wrote:


On Thu, Jun 14, 2018 at 5:47 AM, James Le Cuirot <chewi@g= entoo.org> wrote:
On= Mon, 11 Jun 2018 09:28:37 -0400
Rich Freeman <rich= 0@gentoo.org> wrote:

> All that said, I haven't used the gitlab core functionality
> personally, so I can't vouch for how it stands up on its own again= st
> github.=C2=A0 I might go deploy it in a container or something to try = it
> out.

I used our own self-hosted instance at work. I think it is perfectly=
adequate. I haven't dug in but it seems to have quite a rich API so
there's lots of potential.

> My understanding is that the main barrier to having Gentoo infra host<= br> > gitlab is ruby - they don't like ruby (I don't know all the re= asons -
> they're probably good ones).=C2=A0 If github.com is offering free host= ing
> that would be a way to get out of that problem.=C2=A0 On the other han= d, if
> something bad does happen down the road, there is always the chance > that we'll have to move to self-hosting without a lot of warning, = and
> that means having to deal with ruby whether we like it or not (or lose=
> stuff like issues/PRs/etc that aren't in git itself).

There are more than two options available here.

There are various cloud options including Docker, Kubernetes, and
OpenShift. I don't know much about that.

GitLab's preferred method of installation is their Omnibus packages for=
various distributions but obviously not Gentoo. This is basically
uber-bundling where they bundle just about everything including
PostgreSQL. I have not tried this method. I don't know how feasible or<= br> even desirable it would be to try and use these.

There is a Chef cookbook for installing the Omnibus packages but this
is limited to the same set of distributions.

There is also an unofficial Chef cookbook for installing "from source&= quot;
that I currently maintain, somewhat minimally. Unfortunately it only
supports RHEL (and derivatives) and Debian, and I only test on CentOS.
Their own documentation for installing from source is fairly
comprehensive but the cookbook gives a good indication of how you can
script it up.

https://github.com/atomic-penguin/cookbo= ok-gitlab-deprecated

When we say "from source", what we actually mean is that the vari= ous
dependencies, apart from the Ruby gems and JavaScript libraries, are
installed from distro packages where possible or from source when the
packages are too old. This includes Ruby itself, Go, NodeJS,
PostgreSQL, Redis, nginx, and obviously git. I expect Gentoo would have
no trouble providing recent enough versions of these. You then clone
the various GitLab repositories (currently 4, could be worse), build
the Go code, and install further dependencies with Bundler and YARD,
before doing some final setup tasks and firing it up.

Using Bundler and YARD goes against Gentoo packaging but the list of
dependencies for both sides is extremely long. I very much doubt we
could keep on top of that and I understand this kind of pain because
this is the same situation that the Java team finds itself in. At least
in this case, there are most likely no pre-compiled binaries involved
so the benefits of packaging are limited anyway. Ruby gems that include
native code typically build from source on installation.

I can't comment much about the JavaScript side but on the Ruby side, there are Gemfile.lock files present that lock the Ruby gem
dependencies down to specific versions. If we did want to package the
gems, we would probably not want to be tied to such specific versions.
You could possibly delete these and fall back to the looser constraints
in the Gemfiles but you may run into unexpected issues. You could argue
that we may want to do this even if we don't package the gems in order<= br> to benefit from fixes (including security) but GitLab is very actively
maintained and the lock files are frequently updated.

Keep in mind that GitLab is a very fast-moving project. Security issues
are frequently found but these are fixed quickly. This is not the sort
of project we could install once and then maybe patch up just once a
year or so.


They seem to offer docker packages, so= we could just nab those and run them in containers on hosts. I'm not t= oo keen on doing a bunch of (really what I consider busywork) to try to = 9;get it working on Gentoo.' We already use upstream provided container= s and I expect that to continue as upstreams continue to abandon the 'r= elease packages' model and move to 'release sets of containers'= model.

-A
=C2=A0
I hope you found this informative!

Regards,
--
James Le Cuirot (chewi)
Gentoo Linux Developer




--
Mauricio Lima= Pilla, D.Sc.
http://beagle.ufpel.edu.br/~pilla

pilla@ufpel.edu.br, mauricio.pilla@gmail.com, pilla@gentoo.org
"I'm just very selective about the reality I choose to accept= ."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 -- Calvin
--000000000000268394056e9ade08--