Re: [gentoo-project] utilizing GH functionality that Gentoo infra does not provide

[Mike Frysinger]

On 29 Mar 2022 12:29, Alec Warner wrote:
> On Tue, Mar 29, 2022 at 10:56 AM Mike Frysinger wrote:
> > starting a dedicated thread for
> > https://archives.gentoo.org/gentoo-project/message/ec2b560480627371a7bda5c85924eddd
> >
> > GH provides a lot of functionality for free that Gentoo infra does not cover.
> > these are particularly useful for projects that are used beyond Gentoo.
>
> GH is non-free, and so in the spirit of the social contract, I do not
> believe it should be used. Arguably it shouldn't be used now, but we
> have not stood up an alternative. The alternative is currently in
> alpha (see notes below.)

this argument doesn't really hold water.  we already have core packages (e.g.
portage & catalyst) that hard depend on 3rd party packages that only exist on
GH.  we also have many 1st party packages (i.e. ones authored by Gentoo devs)
that only exist on GH.  this includes core python packages as well as both of
the init systems that Gentoo uses (OpenRC & systemd).

the proposal isn't talking about using GH for code hosting.  that remains on
Gentoo infra.  it also isn't about issue tracking which we have bugs.g.o for.
this is about features that cost nothing and aren't problematic if they're
lost (i.e. GH shuts down).

further, let's see what the social contract actually says:
> We will release our contributions to Gentoo as free software, metadata or
> documentation, under the GNU General Public License version 2 (or later, at
> our discretion) or the Creative Commons - Attribution / Share Alike version
> 2 (or later, at our discretion). Any external contributions to Gentoo (in
> the form of freely-distributable sources, binaries, metadata or documentation)
> may be incorporated into Gentoo provided that we are legally entitled to do
> so. However, Gentoo will never depend upon a piece of software or metadata
> unless it conforms to the GNU General Public License, the GNU Lesser General
> Public License, the Creative Commons - Attribution/Share Alike or some other
> license approved by the Open Source Initiative (OSI).

all the code is still GPL-2, and we're hosting it.

if you're going to try and argue that the hosting services of software we
depend on all have to be FOSS, then that ship sailed long ago (if it even
ever made it to port).  it's logically reductive to the point of irrelevance.
do we require our mirrors to only run FOSS when they host our distfiles or
rsync trees or git repos ?  if we're running in a VM, do we require the VM
host to only run FOSS ?  if it's running in a container, do we require the
container software & host to only run FOSS ?  do we require the hardware
vendors themselves to be FOSS (i.e. Intel's ME & firmware) ?  where exactly
does it end ?

> > * CI runs (e.g. GH actions)
>
> We have CI but it's mostly not self-service and the primary issue on
> the infra-side is always resources / people. I agree we should aim for
> something more accessible.

i don't see why we would waste our money & resources when there places like
GH are throwing tons of free resources.  is our CI going to support multiple
OS's ?  are we going to pay the licensing fees for running on proprietary
OS's (e.g. Windows) ?  what about multiple Linux distros ?  multiple arches ?
can it actually scale to all our needs ?  who gets to maintain all that and
actually keep it working ?  this is more than a full time job, and asking
every dev to chip in only leads to infra that risks falling apart every
other week.

does it really make sense to spend limited engineering time requiring
everyone to use these subpar systems ?

if people want to volunteer to work on it for Gentoo, that's fine of course,
but that doesn't mean we should require every Gentoo project to only use
these.

> > * Projects for task management
>
> I'm not sure what this is (I haven't used it.) We use bugzilla for
> task management (issues) and mailing lists (for discussion.) I'm not
> sure github issues are "better" but they do have some advantages; I've
> gotten complaints about bugzilla, particularly on mobile. Plus you
> cannot reply to bugs easily via email.
>
> For the time being the gitlab alpha does not intend to move issues out
> of bugzilla; nor use gitlab for discussions; aside from discussions on
> PRs (which will be on gitlab.)

the lack of e-mail gateway is kind of annoying.  i'm not super tied to this
particular feature, just another one that i noticed could be of value, and
where bugzilla is a poor substitute.  not sure how many projects would use
it in practice.

gitlab seems to support these though, so it's less of an issue.

> > * possibly even Discussions since it'll provide a clear/scoped space for
> > non-Gentoo users & devs. Gentoo forums are huge and require custom accts,
> > and mailing lists are huge and a bit restrictive old timey.
>
> We have an SSO solution (sso.gentoo.org) that we are rolling out for
> developers, and our gitlab (in alpha testing) will support external
> account providers (probably google, gitlab, github accounts.)
>
> I'm honestly unsure how to receive feedback like "mailing lists are a
> bit restrictive old timey". What does that mean?
>
>  - It's hard to know which list to email.
>  - I often have to subscribe to the list to post.
>  - Hard to have pretty content in an email.

managing subscriptions is archaic.  it's been archaic for years.  you have
to manually construct the e-mail address to send messages to.
https://www.gentoo.org/get-involved/mailing-lists/instructions.html

jumping through these hoops just to start a conversation means people don't.
mailing lists have fallen out of favor as modern communication methods -- see
the rise of web-based services.  i'm not suggesting we migrate to e.g. slack.

more to the point, we don't have localized low-friction spaces.  we don't
have that many mailing lists.  they lock out people (e.g. gentoo-dev) or
they're large & noisy (gentoo-users) or they're still larger in scope (e.g.
the arch lists).  creating mailing lists is painful, and doesn't help that
much with the other points.

> > this is all orthogonal to the git content itself (objects, branches, tags,
> > etc...). those should remain in the read-only clobber mode that exists now.
> >
> > there is no downside for Gentoo here.  it's all functionality that can be
> > had for free, does not introduce any risks, and many devs are already using
> > GH heavily for Gentoo projects -- albeit, they don't do it under the Gentoo
> > umbrella, they fork it into their own personal space and maintain it there.
> > we shouldn't be forcing devs & projects away from Gentoo for such basic
> > functionality.
>
> I think you present a 'free lunch' here and I'll just say "there is no
> such thing as a free lunch." The downside is that we present Gentoo as
> an open distro that doesn't depend on proprietary software, but is
> developed using Github, a proprietary solution that provides all this
> cool functionality that we don't have implemented in house. In general
> that's not a sustainable approach. I get that we make tradeoffs
> (firmware, drivers, being an obvious place where compromises are
> made.) I'm not sure I'm willing to support this one.

are you planning on mandating @system packages and all their deps to not
use GH ?  or packages that Gentoo devs are maintaining that are only used
by Gentoo to not use GH ?  or that those packages have to use GPL-2(+) ?
there's a number of core Gentoo projects right now that are absolutely
violating the social contract by using BSD licenses instead of GPL, but
no one is saying anything about it.

are you saying that things like Gentoo/Prefix are not welcome here just
because they run on Windows or macOS or other proprietary OS's ?  there's
a lot of code that isn't useful at all when you take away these things.

i think you're extrapolating the social contract beyond what it actually is.
Gentoo isn't GNU.  everything we produce is FOSS which is what the social
contract dictates.  it isn't that everything has to be GPL down to the CPU.

not all Gentoo projects are purely about Gentoo.  they might have started
here, and focus on here, but are usable beyond.  how does kicking them out
of the Gentoo umbrella help anyone ?
-mike