[gentoo-project] Repo mirror & CI: official statement wrt GitHub

[gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Michał Górny]

Hi, everyone.

As the lead (and practically the only active developer) of Repository
mirror & CI project, I would like to give you a quick update on my plans
wrt GitHub.  The project is currently using GitHub in two ways:

1. to host mirrors of ebuild repositories on GitHub (the Gentoo
repository is also mirrored to git.g.o);

2. to process pull requests to gentoo/gentoo on GitHub -- to ping
developers and run CI on PRs.

As most of you have probably heard by now, Microsoft will be acquiring
GitHub [1].  This has caused a lot of fuzz, and a lot of projects have
started packing their stuff and moving out.  However, I don't really see
much of a purpose in that right now.

[1]:https://blog.github.com/2018-06-04-github-microsoft/


Mirrors
-------
There are two reasons why repository mirrors are using GitHub.
The technical reason is that it has a trivial API for creating
and maintaining a lot of repositories automatically.  The legal reason
is that it keeps all the 'potentially uncertain' stuff out of Gentoo
infrastructure.

I have been considering moving repository mirrors to Gentoo
infrastructure.  However, the project aims to mirror all repositories
listed in repositories.xml, and we neither can nor really want to
actively monitor the content of all of them.  What we're trying to avoid
is pulling into public Gentoo git repositories data that could end up
causing a legal threat to the infrastructure.

That said, I wouldn't mind adding additional git.gentoo.org mirrors for
the official Gentoo repositories that are hosted on git.gentoo.org
already (since obviously there's no more threat in that).  Please ping
me privately if there's interest in that, and I'll look into extending
the scripts to handle this.

As for moving mirrors elsewhere, I don't really see much of a purpose
in doing that; at least as long as GitHub provides the service for free
and doesn't complain about the space or the traffic involved.
The primary use of the service is through git, so I don't really think
it matters where the servers stand.  Moving them elsewhere sounds like
an unnecessary complexity for our users who'd have to update repos.conf.


Pull requests
-------------
The pull request support was oriented on GitHub for a very simple
reason: because it had a lot of users, therefore it was convenient
for a lot of people.  Now that GitHub is losing users, this argument may
stop being valid at some point.

I'm ready and willing to support GitHub pull requests as long as there's
interest in contributors using them, and the terms of service don't
cause us any major trouble.  That said, this particular project doesn't
have much of a say how users decide to submit contributions and/or how
developers wish to accept them.

If alternative platforms (e.g. GitLab) receive official Gentoo ebuild
repository mirror and gains a significant interest in pull request
assignment and/or CI services, I'm willing to extend the scripts to
handle that.  However, this highly depends on developer support
(i.e. there's no point in another pull request repository if every other
pull request would be saying 'this dev is not here, file a bug instead')
and time to update the scripts for the appropriate API.


To those who believe moving out of GitHub is the only thing to do,
I would like to remind you of two things.  Firstly, if Microsoft indeed
has malicious intent, then they've already won because you've let them
fragment the community.  Secondly, how do you know that GitLab won't be
sold to another 'big player' soon enough?

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

>>>>> On Sat, 09 Jun 2018, Michał Górny wrote:

> To those who believe moving out of GitHub is the only thing to do,
> I would like to remind you of two things. Firstly, if Microsoft
> indeed has malicious intent, then they've already won because you've
> let them fragment the community. Secondly, how do you know that
> GitLab won't be sold to another 'big player' soon enough?

GitLab is free software though, so one can always host one's own
instance of it. This is not possible with GitHub which is proprietary.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Michał Górny]

W dniu sob, 09.06.2018 o godzinie 09∶50 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Sat, 09 Jun 2018, Michał Górny wrote:
> > To those who believe moving out of GitHub is the only thing to do,
> > I would like to remind you of two things. Firstly, if Microsoft
> > indeed has malicious intent, then they've already won because you've
> > let them fragment the community. Secondly, how do you know that
> > GitLab won't be sold to another 'big player' soon enough?
> 
> GitLab is free software though, so one can always host one's own
> instance of it. This is not possible with GitHub which is proprietary.
> 

...and how is this relevant when people are moving to gitlab.com rather
than their own instance?  Also, isn't GitLab partially proprietary?

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 2164 bytes --]

Hi,

we need to be careful with terms:

GitLab can be a "software", which is free and open-source.

But there's also a company named "GitLab Inc." following the open-core
business model providing mostly hosting services for GitLab software
(own instances on-premises, public cloud or SaaS but you can also pay
them to drive GitLab software development in your direction or implement
solutions you need).

This is exactly the same like the situation with GitHub Inc. The only
difference is that GitHub has no free _software suite_ like the GitLab
software.

So both companies are privately held and _can be sold_ _to anyone_ _at
anytime_ following US rules (because both companies are US companies)
like happened with GitHub Inc. which was recently acquired by Microsoft.


When Michał is talking about pull requests he was referring to GitHub
Inc.'s SaaS offering (i.e. the service you can reach via
https://github.com/) and the same equivalent is GitLab Inc.'s Saas
offering (i.e. the service you can reach via https://gitlab.com/).

So if people move from GitHub's SaaS offering to GitLab's SaaS offering
or back to Sourceforge for example (*SCNR*), it could make sense to
offer same/move support for these platforms.

Note: GitLab's recent announcement that GitLab Ultimate and Gold now
free for education and open source is special. While you can integrate
login with GitLab Inc's SaaS platform (i.e. to allow all the existing
https://gitlab.com users to use your issue tracker without the need to
create a new login for you instance), any on-premise solution
("Ultimate" plan for example) is an own walled instance (at least at the
beginning). So you can't just fork https://gitlab.gnome.org/ in you
https://gitlab.com/<username>/ account and do pull requests like you are
used to from GitHub (that's because most people have only dealt with
GitHub's SaaS service and not with any project using GitHub's on-premise
offer) via UI (yes, because it is git you can do it manually but no pull
requests).


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Kristian Fiskerstrand]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

It doesn't matter to much for repo hosting itself, although is a vector for issue tracker, wiki etc if things can be exported / backed up that can then be spun up in an own instance. 
-------- Original message --------From: Michał Górny <mgorny@gentoo.org> Date: 6/9/18  09:52  (GMT+01:00) To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub 
W dniu sob, 09.06.2018 o godzinie 09∶50 +0200, użytkownik Ulrich Mueller
napisał:
> > > > > > On Sat, 09 Jun 2018, Michał Górny wrote:
> > To those who believe moving out of GitHub is the only thing to do,
> > I would like to remind you of two things. Firstly, if Microsoft
> > indeed has malicious intent, then they've already won because you've
> > let them fragment the community. Secondly, how do you know that
> > GitLab won't be sold to another 'big player' soon enough?
> 
> GitLab is free software though, so one can always host one's own
> instance of it. This is not possible with GitHub which is proprietary.
> 

...and how is this relevant when people are moving to gitlab.com rather
than their own instance?  Also, isn't GitLab partially proprietary?

-- 
Best regards,
Michał Górny



[-- Attachment #2: Type: text/html, Size: 1619 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Rich Freeman]

On Sat, Jun 9, 2018 at 3:52 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> W dniu sob, 09.06.2018 o godzinie 09∶50 +0200, użytkownik Ulrich Mueller
> napisał:
> > > > > > > On Sat, 09 Jun 2018, Michał Górny wrote:
> > > To those who believe moving out of GitHub is the only thing to do,
> > > I would like to remind you of two things. Firstly, if Microsoft
> > > indeed has malicious intent, then they've already won because you've
> > > let them fragment the community. Secondly, how do you know that
> > > GitLab won't be sold to another 'big player' soon enough?
> >
> > GitLab is free software though, so one can always host one's own
> > instance of it. This is not possible with GitHub which is proprietary.
> >
>
> ...and how is this relevant when people are moving to gitlab.com rather
> than their own instance?  Also, isn't GitLab partially proprietary?
>

I was at a conference this weekend and chatted quite a bit with a
Gitlab employee about some of this.

My understanding is that Gitlab is open core.  The core part is the
same between their proprietary and FOSS products (I have to take his
word for that, but he is in a position to know and I trust him - knew
him well before he worked for Gitlab).

The proprietary part can be licensed for self-hosting, or the whole
thing can be hosted by them.  Right now they're offering both of those
options to FOSS projects for-free if they don't have paid contributors
(I imagine Gentoo would qualify at present if we wanted to pursue
either).

A rough comparison of the features of the various options can be found at:
https://about.gitlab.com/pricing/

While there might be some proprietary features that we might find
useful, it seems like just the core could be a viable Github
replacement, and that is 100% FOSS (however, I have not actually used
it - I'm going by the feature list).  We could still use gitlab.com
for hosting, but as long as we're taking backups/etc we would always
have the option to move back to self-hosting.  We would simply not use
the proprietary features, other than things like support/etc (hey, if
they're willing to offer us SLAs/etc for the hosting and all that no
reason we can't take advantage - that doesn't really come with any
cost to us long-term).

I think the key is to maintain the ability to self-host at a later
time if we wish, which means avoiding the proprietary bits, or using
them only for non-core stuff like is done with Github today.

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.

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

Now, mgorny basically did a lot of the github stuff on his own
initiative.  That isn't an option with gitlab.com since the distro
would probably have to formally apply for access.  I'm also not sure
how user accounts and such work in that scenario.  I think they
usually charge by the user - so presumably people can't just create
their own accounts and just go to work the way they can on github.
Even if we aren't paying the provisioning process might be more
top-down.  In any case, it seems like any move to gitlab would
probably have to be a bit more official, even if it is just one more
additional service we offer and not a full migration.

I think mgorny has the wait-and-see strategy right - it isn't like
github is going anywhere anytime soon.  If the CI features of
gitlab/etc are useful that might be a reason to consider applying to
use it even as just an add-on.

-- 
Rich

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[James Le Cuirot]

On Mon, 11 Jun 2018 09:28:37 -0400
Rich Freeman <rich0@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 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.

I hope you found this informative!

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

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 4670 bytes --]

On Thu, Jun 14, 2018 at 5:47 AM, James Le Cuirot <chewi@gentoo.org> wrote:

> On Mon, 11 Jun 2018 09:28:37 -0400
> Rich Freeman <rich0@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 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
>
>

[-- Attachment #2: Type: text/html, Size: 5878 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Mauricio Lima Pilla]

[-- Attachment #1: Type: text/plain, Size: 5753 bytes --]

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 <antarus@gentoo.org> wrote:

>
>
> On Thu, Jun 14, 2018 at 5:47 AM, James Le Cuirot <chewi@gentoo.org> wrote:
>
>> On Mon, 11 Jun 2018 09:28:37 -0400
>> Rich Freeman <rich0@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 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

[-- Attachment #2: Type: text/html, Size: 7629 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[kuzetsa]

[-- Attachment #1.1: Type: text/plain, Size: 2421 bytes --]

On 06/09/2018 03:25 AM, Michał Górny wrote:

{...}

> As for moving mirrors elsewhere, I don't really see much of a purpose
> in doing that; at least as long as GitHub provides the service for free
> and doesn't complain about the space or the traffic involved.
> The primary use of the service is through git, so I don't really think
> it matters where the servers stand.  Moving them elsewhere sounds like
> an unnecessary complexity for our users who'd have to update repos.conf.

{...}

> I'm ready and willing to support GitHub pull requests as long as there's
> interest in contributors using them, and the terms of service don't
> cause us any major trouble.  That said, this particular project doesn't
> have much of a say how users decide to submit contributions and/or how
> developers wish to accept them.

{...}

> To those who believe moving out of GitHub is the only thing to do,
> I would like to remind you of two things.  Firstly, if Microsoft indeed
> has malicious intent, then they've already won because you've let them
> fragment the community.  Secondly, how do you know that GitLab won't be
> sold to another 'big player' soon enough?

This is sensible to me.

for non-developers who already contribute using a
git-based workflow, all github does (for example: for me
in-particular) is provide a convenient way to validate
that the commit was made by me and not someone else.

so long as repoman's default requirement that commits
should be signed, the github infrastructure knows which
PGP key is mine, and marks my commits as verified. for my
comfort, the increased effort to use a different workflow
(switching infra for git pushes) would be trivial, but
the burden is still a burden. a needless burden.

adding an //alternative// won't help me personally, but I
can only speak for myself. maybe some people feel more
strongly and would prefer a boycott. I'm not advocating
for this, but if some people opt to do so I'll probably
just keep using my current workflow. the added effort
to use a different method should be optional, I feel.

I see no utility to fix something which some people feel
isn't broken. so long as dropping github doesn't happen,
adding gitlab (or any other method) shouldn't affect me.
rather, it would add //an option// for people who feel the
need to use "not github", and that //can// be a positive.

--kuza


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1094 bytes --]

On 2018-06-14 21:55, kuzetsa wrote:
> for non-developers who already contribute using a
> git-based workflow, all github does (for example: for me
> in-particular) is provide a convenient way to validate
> that the commit was made by me and not someone else.
> 
> so long as repoman's default requirement that commits
> should be signed, the github infrastructure knows which
> PGP key is mine, and marks my commits as verified. for my
> comfort, the increased effort to use a different workflow
> (switching infra for git pushes) would be trivial, but
> the burden is still a burden. a needless burden.

GitHub's feature to display "verified" status has zero meaning for the
Gentoo project. We only trust our own key store.

But this all doesn't matter:
GitLab for example offers a similar feature. I.e. you can add your
public key to your GitLab.com account like you did with your GitHub.com
account and GitLab will display the same "verified" indicator.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 783 bytes --]

On 2018-06-14 16:14, Alec Warner wrote:
> 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.

Huh? Is this the Gentoo-way? I hope not! :(

No, I really hope something like that will never happen. Like I hope we
will never see the attempt to add "FLATPAK", "Snap"... to the official
Gentoo repository.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Aaron W. Swenson]

[-- Attachment #1.1: Type: text/plain, Size: 1156 bytes --]

Actually, somebody has an overlay focused on GitLab ebuilds. I used it for a bit at work, but it was too much of a resource hog for the server I was allowed.

Otherwise, it was quite nice. 

On June 14, 2018 8:33:32 PM EDT, Thomas Deutschmann <whissi@gentoo.org> wrote:
>On 2018-06-14 16:14, Alec Warner wrote:
>> 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.
>
>Huh? Is this the Gentoo-way? I hope not! :(
>
>No, I really hope something like that will never happen. Like I hope we
>will never see the attempt to add "FLATPAK", "Snap"... to the official
>Gentoo repository.
>
>
>-- 
>Regards,
>Thomas Deutschmann / Gentoo Linux Developer
>C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #1.2: Type: text/html, Size: 1435 bytes --]

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 281 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]

On Thu, Jun 14, 2018 at 8:33 PM, Thomas Deutschmann <whissi@gentoo.org>
wrote:

> On 2018-06-14 16:14, Alec Warner wrote:
> > 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.
>
> Huh? Is this the Gentoo-way? I hope not! :(
>
> No, I really hope something like that will never happen. Like I hope we
> will never see the attempt to add "FLATPAK", "Snap"... to the official
> Gentoo repository.
>

I think you will find that vendors who offer fairly complex applications
will continue to focus on vertically integrated solutions
(e.g. containers) because its cheaper (build once run anywhere) and
scalable (you don't need to maintain N packages, for N distros.)

I won't comment on what the "Gentoo" way is (because there are dozens of us
and we don't all agree) but as a human trying to deploy these sorts of
services; I don't see much point in packaging them when upstream offers a
container deployment. Given the dozens of hours I could spend trying to
write ebuilds for all of the bundled stuff vs deploying the container..I'm
going to deploy the container most of the time precisely because I don't
need the 'gentoo customized build', particularly when containers offer
isolation boundaries between the application runtime and my system runtime.

Obviously containers have their own customization challenges (but also
provide layers of isolation where extreme customization is lower priority
than 10 years ago) and also present interesting security challenges (how do
you keep up to date, you cannot use more traditional security tools) but I
suspect organizations can adapt to the former and the industry will provide
for the latter at some point.

-A


>
> --
> Regards,
> Thomas Deutschmann / Gentoo Linux Developer
> C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
>
>

[-- Attachment #2: Type: text/html, Size: 2916 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[kuzetsa]

On 06/14/2018 08:26 PM, Thomas Deutschmann wrote:

> GitHub's feature to display "verified" status has zero meaning for the
> Gentoo project. We only trust our own key store.
> 
> But this all doesn't matter:
> GitLab for example offers a similar feature. I.e. you can add your
> public key to your GitLab.com account like you did with your GitHub.com
> account and GitLab will display the same "verified" indicator.

I think I understand that viewpoint, but there's nuance:

(it matters "more than zero", as you claimed)

if proxy-maintainers or other contributors have no
assurance that they aren't being impersonated, then
a person in bad faith could spoof a submission.

it's a matter of convenience for the committing dev
to be able to verify my key was used for a commit.

I'm aware that a gentoo developer who does the actual
commit will use their own key for the commit which
is entered into the proper git tree.

It's still a matter of convenience. an assurance that
there's some way which contributors can have "not zero"
trust that a commit wasn't wrongly made on their behalf
(malicious chain of custody on some level)

(TIL - as you say, gitlab has this feature too. cool)

--kuza

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 618 bytes --]

On 06/15/2018 04:16 AM, Alec Warner wrote:
> I won't comment on what the "Gentoo" way is (because there are dozens of
> us and we don't all agree) but as a human trying to deploy these sorts
> of services; I don't see much point in packaging them when upstream
> offers a container deployment

How would you track updates to a library for security issues when there
are multiple versions in different containers, and you're not building
the container yourself?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 2378 bytes --]

On 2018-06-15 04:27, kuzetsa wrote:
> I think I understand that viewpoint, but there's nuance:
> 
> (it matters "more than zero", as you claimed)
> 
> if proxy-maintainers or other contributors have no
> assurance that they aren't being impersonated, then
> a person in bad faith could spoof a submission.
> 
> it's a matter of convenience for the committing dev
> to be able to verify my key was used for a commit.

No! And I really hope nobody is doing that:

Anyone with access to your GitHub account can add new keys. _We_ will
not notice if _you_ or an attacker changed your account. Therefore, any
third party for key management isn't an option and _must be_ ignored.

We can only rely on our own key management. If an attacker is able to
manipulate Gentoo LDAP (our single point of truth), Gentoo is lost. But
until such a scenario, this is the only reliable way to verify and
assume something. I.e. you cannot outsource identity management to a
self-service portal as offered by GitHub's account preferences.

It would be nice to maintain proxy maintainer's keys in a similar way.
However, given that proxy maintainer's signature will never appear in
Gentoo repository (it is always the developer's signature which will
replace the proxy maintainer's signature), there's no need to do
something like that at the moment because we have nothing to verify.

In summary:

- Any Gentoo developer who proxies someone should never ever trust a
third part for identity management. Trust must be established between
the dev and the proxy maintainer.

- For Gentoo developers it is important to understand that you are
reliable for anything signed by your key. So it doesn't really matter if
the PR was spoofed or not. It does only matter if the commit was harmful
or not. If there will ever be any doubts, it was _you_ (the Gentoo
developer) who caused the resulting problem because you approved and merged.

- Gentoo proxy-maintenance project is not a "push-through" service. :)

- Having green "verified" indicators on commit view next to each commit
on GitHub or any other non-Gentoo service is dangerous. Don't trust
these indicators. They don't have a meaning for Gentoo, only for the
platform you are using.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[kuzetsa]

On 06/15/2018 07:50 AM, Thomas Deutschmann wrote:
> On 2018-06-15 04:27, kuzetsa wrote:
>> I think I understand that viewpoint, but there's nuance:
>>
>> (it matters "more than zero", as you claimed)
>>
>> if proxy-maintainers or other contributors have no
>> assurance that they aren't being impersonated, then
>> a person in bad faith could spoof a submission.

{...}

> We can only rely on our own key management. If an attacker is able to
> manipulate Gentoo LDAP (our single point of truth), 

{...}

{...} /// proxy maintainer's signature will never appear in
> Gentoo repository (it is always the developer's signature which will
> replace the proxy maintainer's signature), there's no need to do
> something like that at the moment because we have nothing to verify.

{...}

> - For Gentoo developers it is important to understand that you are
> reliable for anything signed by your key. So it doesn't really matter if
> the PR was spoofed or not. /// {...}
I'm aware of this, and it's part of what I'm troubled by:

the act of throwing away signatures from contributors is
a thing which I had considered mentioning in a different
context: ["Would you sign a Contributor License Agreement?"]

"Gentoo Developer's Certificate of Origin" - shouldn't
the author / contributor themselves be involved in this?

contributor keys /do/ matter, at least until the point
where a commit is in the tree (with signature replaced)

at some point, the contributor exercises their judgment
in saying to themselves: "yes, this matches what I wrote",
and will then reconcile their local git tree with the
official (developer-signed) one.

^ meta-stuff for non-developer contributions ::sigh::

- for the original thing I was trying to say:

the analogy could be made where an employer insists that
all wages are issued to a preloaded debit card, rather
than a bank transfer or paycheck which gets handled by
the financial institution designated by each employee.

while possible that banks could do something malicious,
/not/ having a bank would increase the counterparty risk
for employees; separation of duties might be an apt term?

involving a 3rd party means the option is available to spot
any discrepancies between activity / commits in the gentoo
tree, versus the tree (on github, or any other 3rd party)
which a contributor has made transparent / visible.

-- kuza

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Rich Freeman]

On Fri, Jun 15, 2018 at 10:55 AM kuzetsa <kuzetsa@gmail.com> wrote:
>
> "Gentoo Developer's Certificate of Origin" - shouldn't
> the author / contributor themselves be involved in this?
>

It already requires this.  The committer would have to certify:

" (4) The contribution was provided directly to me by some other person
        who certified (1), (2), (3), or (4), and I have not modified it."

(or one of the other items in the list, if they did modify it)

Ultimately the committer is the person Gentoo has a relationship with,
so they need to make the certification when they make the commit, even
if it is just certifying that somebody else certified it.

This goes along with something Thomas said earlier - ultimately the
committers are responsible for what they commit.  There really isn't a
sane alternative since the whole reason we try to control our
committers is to ensure that things don't end up in the repository
which shouldn't be there.  This isn't diminishing the value of 3rd
party contributors - but simply affirming the value-add of having
somebody we know actually look at what is being contributed.  That
includes the copyright/license and not just the code.  After all, all
this stuff ends up on all our users's systems so we want to protect
them as well as ourselves.  Users already have the freedom to use any
overlays they wish if they value these things differently.

--
Rich

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[kuzetsa]

On 06/15/2018 11:31 AM, Rich Freeman wrote:
> On Fri, Jun 15, 2018 at 10:55 AM kuzetsa <kuzetsa@gmail.com> wrote:
>>
>> "Gentoo Developer's Certificate of Origin" - shouldn't
>> the author / contributor themselves be involved in this?
>>
> 
> It already requires this.  The committer would have to certify:
> 
> " (4) The contribution was provided directly to me by some other person
>         who certified (1), (2), (3), or (4), and I have not modified it."
> 
> (or one of the other items in the list, if they did modify it)
> 
> Ultimately the committer is the person Gentoo has a relationship with,
> so they need to make the certification when they make the commit, even
> if it is just certifying that somebody else certified it.
> 
> This goes along with something Thomas said earlier - ultimately the
> committers are responsible for what they commit.  There really isn't a
> sane alternative since the whole reason we try to control our
> committers is to ensure that things don't end up in the repository
> which shouldn't be there.  This isn't diminishing the value of 3rd
> party contributors - but simply affirming the value-add of having
> somebody we know actually look at what is being contributed.  That
> includes the copyright/license and not just the code.  After all, all
> this stuff ends up on all our users's systems so we want to protect
> them as well as ourselves.  Users already have the freedom to use any
> overlays they wish if they value these things differently.
> 
> --
> Rich
> 

OH!!! (thanks, I completely missed that detail)

from: "$ man git-commit" :  [...] The meaning of a
signoff depends on the project, but it typically
certifies that committer has the rights to submit
this work [...]

this is frustratingly vague (to me), but I suppose
the extra metadata included in the same paragraph
has a link to: https://developercertificate.org/

---
(c) The contribution was provided directly to me
by some other person who certified (a), (b) or (c)
and I have not modified it.
---

^ took me a few minutes to figure out what you meant,
or where that particular quote came from:

I had never considered this, because historically,
gentoo developers who use their PGP key to commit
rarely use the --signoff feature when committing the
submissions of a contributor, and even if they had,
there's not a stable definition.

in particular, I'm considering the meaning of the phrase:

"some other person who certified" - does this mean the
contributor needs to use their PGP key to sign or...?

it would be good for gentoo to have clarity on this.

I think it could lessen feelings / perceptions that
contributors ought to maintain a copy of the work on a 3rd
party mirror until it is no longer useful (IMO, at least).

-- kuza

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Rich Freeman]

On Fri, Jun 15, 2018 at 12:03 PM kuzetsa <kuzetsa@gmail.com> wrote:
>
> from: "$ man git-commit" :  [...] The meaning of a
> signoff depends on the project, but it typically
> certifies that committer has the rights to submit
> this work [...]
>
> this is frustratingly vague (to me), but I suppose
> the extra metadata included in the same paragraph
> has a link to: https://developercertificate.org/

Well, we aren't using that as-is, but a modified version of this.
Gentoo policies aren't contained in manpages.

The Gentoo policy is in draft GLEP 76:
https://gitweb.gentoo.org/data/glep.git/tree/glep-0076.rst

(It was posted a few days ago on this list, and discussed here in
various forms over the last few years.)

> ^ took me a few minutes to figure out what you meant,
> or where that particular quote came from:

It came from GLEP 76 (still in draft).  It is of course based on the
Linux DCO (which I believe is attributed in the GLEP).

> I had never considered this, because historically,
> gentoo developers who use their PGP key to commit
> rarely use the --signoff feature when committing the
> submissions of a contributor, and even if they had,
> there's not a stable definition.

Today they shouldn't be using --signoff, because there IS no official
policy.  They will be required to do so once GLEP 76 is approved (this
will be enforced with a commit hook).

> "some other person who certified" - does this mean the
> contributor needs to use their PGP key to sign or...?
>
> it would be good for gentoo to have clarity on this.

IMO it is up to the certifier to decide what constitutes a
certification made by somebody else.  This is necessarily outside of
Gentoo so to try to impose a particular mechanism would make it harder
to use outside code.  For example, all Linux commits have a DCO
signoff, but these have no GPG signoffs to go with them.  We wouldn't
want to block people from using GPL2 Linux code just because they use
a different mechanism to track such things.

The Gentoo DCO is an agreement between the Gentoo committer (a Gentoo
dev) and Gentoo.

That is roughly how I see it at least.

--
Rich

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[kuzetsa]

On 06/15/2018 12:11 PM, Rich Freeman wrote:
> On Fri, Jun 15, 2018 at 12:03 PM kuzetsa <kuzetsa@gmail.com> wrote:
>>
>> from: "$ man git-commit" :  [...] The meaning of a
>> signoff depends on the project, but it typically
>> certifies that committer has the rights to submit
>> this work [...]
>>
>> this is frustratingly vague (to me), but I suppose
>> the extra metadata included in the same paragraph
>> has a link to: https://developercertificate.org/
> 
> Well, we aren't using that as-is, but a modified version of this.
> Gentoo policies aren't contained in manpages.
> 
> The Gentoo policy is in draft GLEP 76:
> https://gitweb.gentoo.org/data/glep.git/tree/glep-0076.rst
> 
> (It was posted a few days ago on this list, and discussed here in
> various forms over the last few years.)
> 
>> ^ took me a few minutes to figure out what you meant,
>> or where that particular quote came from:
> 
> It came from GLEP 76 (still in draft).  It is of course based on the
> Linux DCO (which I believe is attributed in the GLEP).
> 
>> I had never considered this, because historically,
>> gentoo developers who use their PGP key to commit
>> rarely use the --signoff feature when committing the
>> submissions of a contributor, and even if they had,
>> there's not a stable definition.
> 
> Today they shouldn't be using --signoff, because there IS no official
> policy.  They will be required to do so once GLEP 76 is approved (this
> will be enforced with a commit hook).
> 
>> "some other person who certified" - does this mean the
>> contributor needs to use their PGP key to sign or...?
>>
>> it would be good for gentoo to have clarity on this.
> 
> IMO it is up to the certifier to decide what constitutes a
> certification made by somebody else.  This is necessarily outside of
> Gentoo so to try to impose a particular mechanism would make it harder
> to use outside code.  For example, all Linux commits have a DCO
> signoff, but these have no GPG signoffs to go with them.  We wouldn't
> want to block people from using GPL2 Linux code just because they use
> a different mechanism to track such things.
> 
> The Gentoo DCO is an agreement between the Gentoo committer (a Gentoo
> dev) and Gentoo.
> 
> That is roughly how I see it at least.
> 
> --
> Rich
> 

well golly. that's swell. I hadn't been keeping up with
those details. sounds good. like real good.

(I'll likely be silent for a few days. busy.)

-- kuza

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

Am Donnerstag, 14. Juni 2018, 16:14:48 CEST schrieb Alec Warner:

> 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

Apart from all the implications that have already been brought up, that's

1) a public relations nightmare waiting to happen
(future discussion: "Err, wait, central Gentoo infrastructure runs on an 
Ubuntu-based container? Well, then we switch directly to Ubuntu.")

2) not particularly nice to our users, who probably want to experiment with 
gitlab too.
(Hey, for years www-apps/bugzilla was maintainer-needed while Gentoo Infra was 
running a well-maintained instance. I was always wondering what happened 
there...)

So I'd suggest we either are convinced that our packaging actually makes 
sense, and use it, or we close shop.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Rich Freeman]

On Sat, Jun 16, 2018 at 5:58 PM Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>
> So I'd suggest we either are convinced that our packaging actually makes
> sense, and use it, or we close shop.
>

Perhaps it makes more sense for linked binaries than for scripts or
java (ie, 99% of web hosting)?

In any case, the solution we're using today is Github, which also
doesn't run on Gentoo and is proprietary, because nobody can be
bothered to deal with getting Gitlab to run on Gentoo.  It seems like
at least moving to something that could conceivably be self-hosted on
any distro (perhaps even Gentoo) would be an improvement.

However, as others have pointed out Gitlab apparently needs fairly
frequent updates.  So, it is something that would require a bit of
care.  That would be an argument for hosting it on an
upstream-recommended platform that actually gets updates if we want to
host it ourselves.  If we had a long line of people willing to keep
everything up to date on Gentoo that would be one thing, but right now
it isn't even packaged, which doesn't speak well for rapid security
updates.

I guess in the meantime we can just stick with Github...

-- 
Rich

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

On Sat, Jun 16, 2018 at 5:58 PM, Andreas K. Huettel <dilfridge@gentoo.org>
wrote:

> Am Donnerstag, 14. Juni 2018, 16:14:48 CEST schrieb Alec Warner:
>
> > 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
>
> Apart from all the implications that have already been brought up, that's
>
> 1) a public relations nightmare waiting to happen
> (future discussion: "Err, wait, central Gentoo infrastructure runs on an
> Ubuntu-based container? Well, then we switch directly to Ubuntu.")
>

Its unclear what the upstream containers might be based on. CoreOS or
Alpine Linux are both common bases (and CoreOS is ironically a
Gentoo-powered[1] distro using our tree and tools.) I'm not sure people
would switch because of that.


> 2) not particularly nice to our users, who probably want to experiment
> with
> gitlab too.
> (Hey, for years www-apps/bugzilla was maintainer-needed while Gentoo Infra
> was
> running a well-maintained instance. I was always wondering what happened
> there...)
>

Users who want to experiment with gitlab can install docker and docker pull
the images, same as infra.
If users want to do things with ebuilds they can follow the wiki:
https://wiki.gentoo.org/wiki/GitLab

I'm not yet quite convinced that Infra should be forced to do the latter,
provided the former does not violate the social contract (and that is
perhaps a healthy debate one could have.)


> So I'd suggest we either are convinced that our packaging actually makes
> sense, and use it, or we close shop.
>

I'm not convinced its worthwhile to package gitlab when upstream already
packaged it for us, which is why you don't see me spending time on such
things.

[0] https://github.com/coreos/coreos-overlay


> --
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer
> (council, toolchain, perl, libreoffice, comrel)

[-- Attachment #2: Type: text/html, Size: 3494 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Virgil Dupras]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

On Thu, 14 Jun 2018 22:16:46 -0400
Alec Warner <antarus@gentoo.org> wrote:

> I'm
> going to deploy the container most of the time precisely because I don't
> need the 'gentoo customized build', particularly when containers offer
> isolation boundaries between the application runtime and my system runtime.

I'm under the impression that the Gentoo way is not so much about customization, but about control. We can be fine with running a vanilla instance, but if we're going to depend on it, we have to have the power to bend it to our will. On the practical side of things, depending on a black box (omnibus packaging) isn't so far away from depending on proprietary software. In both cases, we surrender a great deal of control.

I'm thinking that the dilemma here isn't whether to properly package a very complex solution or to use their omnibus deployment solution, but rather whether to avoid the software entirely because it involves too much complexity for our infra team to control properly, the need for omnibus packaging being a kind of tautological threshold (if you need it, then it's too complex for us to use).

Of course, the situation is even worse in this regard with github, but it has inertia on its side.

Regards,
Virgil

[-- Attachment #2: Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Rich Freeman]

On Sat, Jun 16, 2018 at 7:55 PM Virgil Dupras <vdupras@gentoo.org> wrote:
>
>
> Of course, the situation is even worse in this regard with github, but it has inertia on its side.
>

That, and anybody can just create a Gentoo org for free without any
kind of official sanction and without any need to host anything.

Since gitlab.com isn't free (as in beer) somebody would need to
officially apply on behalf of Gentoo to get an instance hosted by
them.  So, that means that there is no unofficial free cloud hosting,
and it will only exist if somebody goes to the considerable trouble to
have it set up on infra (or they host it themselves, which seems
likely to have adoption challenges), or get everbody to agree to
request having it set up with the semi-free (as in freedom) cloud
option.

The reason everybody is using Github is because it provides
functionality not available on Gentoo infra, and it is very easy to
use as an alternative.

-- 
Rich

Re: [gentoo-project] Repo mirror & CI: official statement wrt GitHub

[Brian Dolbec]

On Sat, 16 Jun 2018 19:45:18 -0400
Alec Warner <antarus@gentoo.org> wrote:

> On Sat, Jun 16, 2018 at 5:58 PM, Andreas K. Huettel
> <dilfridge@gentoo.org> wrote:
> 
> > Am Donnerstag, 14. Juni 2018, 16:14:48 CEST schrieb Alec Warner:
> >  
> > > 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  
> >
> > Apart from all the implications that have already been brought up,
> > that's
> >
> > 1) a public relations nightmare waiting to happen
> > (future discussion: "Err, wait, central Gentoo infrastructure runs
> > on an Ubuntu-based container? Well, then we switch directly to
> > Ubuntu.") 
> 
> Its unclear what the upstream containers might be based on. CoreOS or
> Alpine Linux are both common bases (and CoreOS is ironically a
> Gentoo-powered[1] distro using our tree and tools.) I'm not sure
> people would switch because of that.
> 
> 

Except that Red-Hat just bought CoreOS and are intending to replace the
Gentoo base with Red-Hat.  (Reported by one of my co-workers that just
attended the big docker conference and at least one of the talks where
that was discussed)




-- 
Brian Dolbec <dolsen>