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

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

[Mike Frysinger]

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

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.

* release management (e.g. distfiles hosting)
* CI runs (e.g. GH actions)
* Projects for task management
* 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.

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

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

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

[Arthur Zamarin]

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

On 29/03/2022 20.56, 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.
> 
> * release management (e.g. distfiles hosting)
> * CI runs (e.g. GH actions)
> * Projects for task management
> * 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.

I myself agree on this list. I find some of those features quite nice
and helping for my developments for Gentoo, so I can understand why we
would like them.

> 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 know there exist some social contract by Gentoo, which might have
issues with us using GitHub, but I'm not sure I can fully explain it, so
I will leave it for others to explain or debate.

I know this is a future project (with something running currently [1]),
but one day we will have a running Gentoo's GitLab system. I think most
of the features listed above are currently working in the current
instance, with various extra nice things (like bugzilla and IRC
integration), and I think the main thing that isn't setup ready is CI.

GitLab also has mirroring support (I still didn't manage to setup it,
but my experience with such things is very low), so people could use
GitLab mainly, with mirror on GitHub, which might improve our "image".

To summarize my long text, I think that even if we open the GitHub
features (I don't have opinion on it), I think in some time, most of us
will move into Gentoo's GitLab.

> -mike
Thanks for opening this discussion - nice reading from you :)

[1] https://gitlab.gentoo.org/

-- 
Arthur Zamarin
arthurzam@gentoo.org
Gentoo Linux developer (Python, GURU, Arch Teams)

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

[gentoo-project] Gentoo's GitLab (was: utilizing GH functionality that Gentoo infra does not provide)

[Anna Vyalkova]

On 2022-03-29 21:26, Arthur Zamarin wrote:
> I know this is a future project (with something running currently [1]),
> but one day we will have a running Gentoo's GitLab system. I think most
> of the features listed above are currently working in the current
> instance, with various extra nice things (like bugzilla and IRC
> integration), and I think the main thing that isn't setup ready is CI.
> 
> GitLab also has mirroring support (I still didn't manage to setup it,
> but my experience with such things is very low), so people could use
> GitLab mainly, with mirror on GitHub, which might improve our "image".
> 
> To summarize my long text, I think that even if we open the GitHub
> features (I don't have opinion on it), I think in some time, most of us
> will move into Gentoo's GitLab.
> 
> [1] https://gitlab.gentoo.org/

Why GitLab? There are other FOSS forges like Gitea and SourceHut.

Is it chosen because GitLab is familiar to ponential contributors?

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

[Alec Warner]

On Tue, Mar 29, 2022 at 10:56 AM Mike Frysinger <vapier@gentoo.org> 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.)

>
> * release management (e.g. distfiles hosting)

I agree this is a gap.

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

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

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

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

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.

I will tell you I have an alpha version of gitlab up, and I'm looking
for repos to mirror there. If you are satisfied with gitlab as the
platform to provide the features you want I'm happy to set up some
time to get your repos on gitlab; collect requirements, and figure out
what we need to deliver in our gitlab to host your repos (and
eventually all the Gentoo repos.)

Find me on signal or in #gentoo-gitlab on irc.libera.chat.

-A

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

[Mike Frysinger]

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

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

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

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

[Andreas K. Huettel]

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


> * release management (e.g. distfiles hosting)
> * CI runs (e.g. GH actions)
> * Projects for task management
> * 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.
> 

eh... so it's just because it's "huge, restrictive, old timey" that you're never on irc?

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

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

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

[Mike Frysinger]

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

On 29 Mar 2022 21:36, Andreas K. Huettel wrote:
> > * 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.
> 
> eh... so it's just because it's "huge, restrictive, old timey" that you're never on irc?

were you trying to make a point or something ?
-mike

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

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

[David Seifert]

On Wed, 2022-03-30 at 22:01 -0400, Mike Frysinger wrote:
> On 29 Mar 2022 21:36, Andreas K. Huettel wrote:
> > > * 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.
> > 
> > eh... so it's just because it's "huge, restrictive, old timey" that
> > you're never on irc?
> 
> were you trying to make a point or something ?
> -mike

This goes hand in hand with team work realistically only happening on
IRC, and since I've joined, you've never once replied to one of my
emails *ever*. Said differently: trying to work with you is nigh
impossible.

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

[Mike Frysinger]

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

On 31 Mar 2022 10:21, David Seifert wrote:
> On Wed, 2022-03-30 at 22:01 -0400, Mike Frysinger wrote:
> > On 29 Mar 2022 21:36, Andreas K. Huettel wrote:
> > > > * 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.
> > > 
> > > eh... so it's just because it's "huge, restrictive, old timey" that
> > > you're never on irc?
> > 
> > were you trying to make a point or something ?
> 
> This goes hand in hand with team work realistically only happening on
> IRC

point out the policy which mandates IRC usage.  if there isn't one,
then there isn't anything left to discuss.

i'm glad you have time for idle chatter & socialization on a noisy,
unorganized medium.  not everyone does.  the SNR is much too high.

> and since I've joined, you've never once replied to one of my
> emails *ever*

let's see.  looking through my mail archive for "from:soap@gentoo" &
"to:vapier@gentoo" i see 1 hit.  you asking about joining games@ back
in 2016.  you are correct i did not respond to that, and i apologize,
but at that time i had largely stepped back from the team and others
were managing it (Mr. Bones. iirc was POC).  you probably should have
reached out to the entire team via games@gentoo.org instead.

but 1 missed e-mail over 8 years does not seem to back up your claim.
unless you mean you sent me 1 e-mail and i didn't respond, then sure,
i guess that's accurate.

> Said differently: trying to work with you is nigh impossible.

everyone has an opinion.  that is yours.
-mike

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

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

[Andreas K. Huettel]

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

> 
> > Said differently: trying to work with you is nigh impossible.
> 
> everyone has an opinion.  that is yours.

That isn't just soap's opinion.

As a matter of fact a lot of people have tried to work with you in the past and
given up due to your communication style.

And, to be honest, waltzing in and demanding that everything is done differently
after being absent for ages doesn't do you credit either.

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

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

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

[Maciej Barć]

[-- Attachment #1.1.1: Type: text/plain, Size: 2264 bytes --]


> * release management (e.g. distfiles hosting)

The way that I imagine it could happen would be quite weird/complicated 
to use. Mike, could you please expand on how you think this could work?


> * CI runs (e.g. GH actions)


GURU already started experimenting with usage of GH's CI [1],
though I can't skip over a very irritating fact: GH seems to think that 
there is only one Linux-based OS ("runs-on: ubuntu-latest"). IMO it 
would be better to run the CI on Gentoo's containers - which is possible 
with GitLab's CI.
Also, on GitLab we do not have to pull images from official Docker 
registry [2].

But even just using GH's CI to list changes or do some minor check, 
(maybe do not ping everybody to oblivion) would be nice, because as Mike 
pointed out this is without any charge.

[1] https://github.com/gentoo/guru/tree/master/.github/workflows
[2] 
https://gitlab.com/src_prepare/racket/racket-overlay/-/blob/master/.gitlab-ci.yml#L18

On 3/29/22 7:56 PM, 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.
> 
> * release management (e.g. distfiles hosting)
> * CI runs (e.g. GH actions)
> * Projects for task management
> * 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.
> 
> 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.
> -mike

-- 
Have a great day!

~ Maciej XGQT Barć

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6297 bytes --]

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

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

[Michael Jones]

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

On Thu, Mar 31, 2022 at 6:48 AM Maciej Barć <xgqt@gentoo.org> wrote:

> GURU already started experimenting with usage of GH's CI [1],
> though I can't skip over a very irritating fact: GH seems to think that
> there is only one Linux-based OS ("runs-on: ubuntu-latest"). IMO it
> would be better to run the CI on Gentoo's containers - which is possible
> with GitLab's CI.
> Also, on GitLab we do not have to pull images from official Docker
> registry [2].
>

Do you mean to imply that Github's CI doesn't support Linux other than
Ubuntu? Or do you mean instead that Github's CI only supports non-Ubuntu as
docker containers?

An example of using a non-Ubuntu Linux container can be found here:
https://github.com/ninja-build/ninja/blob/25cdbae0ee1270a5c8dd6ba67696e29ad8076919/.github/workflows/linux.yml#L13

But perhaps you already knew that an I simply misunderstood your meaning.

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

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

[Maciej Barć]

[-- Attachment #1.1.1: Type: text/plain, Size: 1348 bytes --]

> An example of using a non-Ubuntu Linux container can be found here: 

Good to know, I think GURU's CI does not utilize that.

On 3/31/22 6:43 PM, Michael Jones wrote:
> 
> 
> On Thu, Mar 31, 2022 at 6:48 AM Maciej Barć <xgqt@gentoo.org 
> <mailto:xgqt@gentoo.org>> wrote:
> 
>     GURU already started experimenting with usage of GH's CI [1],
>     though I can't skip over a very irritating fact: GH seems to think that
>     there is only one Linux-based OS ("runs-on: ubuntu-latest"). IMO it
>     would be better to run the CI on Gentoo's containers - which is
>     possible
>     with GitLab's CI.
>     Also, on GitLab we do not have to pull images from official Docker
>     registry [2].
> 
> 
> Do you mean to imply that Github's CI doesn't support Linux other than 
> Ubuntu? Or do you mean instead that Github's CI only supports non-Ubuntu 
> as docker containers?
> 
> An example of using a non-Ubuntu Linux container can be found here: 
> https://github.com/ninja-build/ninja/blob/25cdbae0ee1270a5c8dd6ba67696e29ad8076919/.github/workflows/linux.yml#L13 
> <https://github.com/ninja-build/ninja/blob/25cdbae0ee1270a5c8dd6ba67696e29ad8076919/.github/workflows/linux.yml#L13>
> 
> But perhaps you already knew that an I simply misunderstood your meaning.

-- 
Have a great day!

~ Maciej XGQT Barć

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 6297 bytes --]

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

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

[Andrew Ammerlaan]

On 31/03/2022 20:07, Maciej Barć wrote:
>
> On 3/31/22 6:43 PM, Michael Jones wrote:
>>
>>
>> On Thu, Mar 31, 2022 at 6:48 AM Maciej Barć <xgqt@gentoo.org 
>> <mailto:xgqt@gentoo.org>> wrote:
>>
>>     GURU already started experimenting with usage of GH's CI [1],
>>     though I can't skip over a very irritating fact: GH seems to think 
>> that
>>     there is only one Linux-based OS ("runs-on: ubuntu-latest"). IMO it
>>     would be better to run the CI on Gentoo's containers - which is
>>     possible
>>     with GitLab's CI.
>>     Also, on GitLab we do not have to pull images from official Docker
>>     registry [2].
>>
>>
>> Do you mean to imply that Github's CI doesn't support Linux other than 
>> Ubuntu? Or do you mean instead that Github's CI only supports 
>> non-Ubuntu as docker containers?
>>
>> An example of using a non-Ubuntu Linux container can be found here: 
>> https://github.com/ninja-build/ninja/blob/25cdbae0ee1270a5c8dd6ba67696e29ad8076919/.github/workflows/linux.yml#L13 
>> <https://github.com/ninja-build/ninja/blob/25cdbae0ee1270a5c8dd6ba67696e29ad8076919/.github/workflows/linux.yml#L13> 
>
 > Good to know, I think GURU's CI does not utilize that.

The ::guru (and ::sci) CI use the pkgcheck GitHub Action [1], very 
useful if you want to quickly setup a CI in your ebuild repository. It 
doesn't really matter which OS you run it on though. All it does is run 
pkgcheck on a collection of ebuild files etc, it will do that just as 
well in a Ubuntu container as in a Gentoo container.

Something that is on my wishlist is to replace this with something 
similar to what we have in ::gentoo (I.e. a CI that not only runs 
pkgcheck but also complains in #gentoo-guru and via email if it is 
broken. Automating this means that I no longer have to do it manually :P)

Best regards,
Andrew

[1] https://github.com/pkgcore/pkgcheck-action

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

[Sam James]

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



> On 29 Mar 2022, at 18:56, Mike Frysinger <vapier@gentoo.org> wrote:
> 
> starting a dedicated thread for
> https://archives.gentoo.org/gentoo-project/message/ec2b560480627371a7bda5c85924eddd
> 

Just as an introduction, I'd like to say I am deeply sympathetic to the need
to be practical and it's easily what I prioritise most. So I do get it.

> 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.
> 
> * release management (e.g. distfiles hosting)

I'm not sure I love this one under the test of "if our GH got wiped tomorrow, would there
be much impact?"

If downstream and others are using e.g. pax-utils with an unreliable SRC_URI,
that *is* a pain, and it's not much comfort to then tell them that it "wasn't
covered by infra anyway" or something.

We do need a proper solution in infra for hosting resources though. I thought
we had a bug for it but I can't find it right this second, bu the idea would be to expand
projects.gentoo.org to more easily host distfiles and stuff independently of
individual developers (whose links go dead when they retire).


> * CI runs (e.g. GH actions)

I don't object to this and free CPU is free CPU. I just wouldn't want to
create binary artefacts from it, but I don't think you're proposing that.

> * Projects for task management

I struggle with this a bit more because it'd hurt archeology efforts
if GitHub got wiped.

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

I'm not opposed to this if it's just for user support / queries rather than
Bugs. Making it easier for people to seek help isn't a bad thing.

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

Yep, and I'm guilty of this as well. I've started making a list of some important
repos we really need to mirror onto our infra at least (inc, but not limited to,
pkgcore).


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

[Sam James]

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



> On 1 Apr 2022, at 02:27, Sam James <sam@gentoo.org> wrote:
>> On 29 Mar 2022, at 18:56, Mike Frysinger <vapier@gentoo.org> wrote:
>> [snip]
> 
>> 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.
> 
> Yep, and I'm guilty of this as well. I've started making a list of some important
> repos we really need to mirror onto our infra at least (inc, but not limited to,
> pkgcore).
> 

Sorry, just to finish making the point I'd intended on here: while this might
be true, I don't think it's a reason to depend on it more where there's
a decent argument against it. It's just a reason to actually migrate
away or at least ensure we have contingencies?


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

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

[Mike Frysinger]

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

On 01 Apr 2022 02:28, Sam James wrote:
> > On 1 Apr 2022, at 02:27, Sam James <sam@gentoo.org> wrote:
> >> On 29 Mar 2022, at 18:56, Mike Frysinger <vapier@gentoo.org> wrote:
> >> [snip]
> > 
> >> 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.
> > 
> > Yep, and I'm guilty of this as well. I've started making a list of some important
> > repos we really need to mirror onto our infra at least (inc, but not limited to,
> > pkgcore).
> 
> Sorry, just to finish making the point I'd intended on here: while this might
> be true, I don't think it's a reason to depend on it more where there's
> a decent argument against it. It's just a reason to actually migrate
> away or at least ensure we have contingencies?

my point is that it's hypocritical to say "Gentoo projects may not use GH"
while actively ignoring that Gentoo projects not under the Gentoo umbrella
are using GH exclusively, and there is no one pushing back against them. [0]

further, since there is nothing in the Gentoo social contract or any other
policy document saying that Gentoo projects may not use GH, banning it is
not justified, and only serves to restrict access to free resources.

if anything, this position actively goes against the Gentoo philosophy [1]:
one based in pragmatism without compromising on the software being free and
open [2].
-mike

[0] to be clear: i'm not saying such projects must move to Gentoo infra.
    i'm fine with them being on GH as long as they're free software and
    their VCS's are readily available.
[1] https://www.gentoo.org/get-started/philosophy/
[2] https://www.gentoo.org/get-started/philosophy/social-contract.html

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

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

[Mike Frysinger]

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

On 01 Apr 2022 02:27, Sam James wrote:
> > On 29 Mar 2022, at 18:56, Mike Frysinger wrote:
> > * release management (e.g. distfiles hosting)
> 
> I'm not sure I love this one under the test of "if our GH got wiped tomorrow, would there
> be much impact?"
> 
> If downstream and others are using e.g. pax-utils with an unreliable SRC_URI,
> that *is* a pain, and it's not much comfort to then tell them that it "wasn't
> covered by infra anyway" or something.

we're already in that situation now.  dev.g.o is very unreliable.  devs clean
their space, or they retire, and all the archives they accumulated vanish when
infra decides to remove their www space.

i'll bet hard cash everytime on GH being more reliable in the short, medium,
and long term than dev.g.o.

> We do need a proper solution in infra for hosting resources though. I thought
> we had a bug for it but I can't find it right this second, bu the idea would be to expand
> projects.gentoo.org to more easily host distfiles and stuff independently of
> individual developers (whose links go dead when they retire).

everyone has been saying this for over a decade.  probably even 2 decades at
this point.  wishing for it doesn't make it happen.  i grok that complaining
about it also doesn't make it happen :p.  but folks who have been infra for a
long time have already thought about & discussed it much longer than i have,
and we're still where we were 20 years ago -- dev.g.o.

it doesn't make sense to me to ban a solution that exists now, and would be
trivial to migrate off of if Gentoo infra ever does come up with a solution.
especially considering many Gentoo devs are using GH right now for Gentoo
projects and the only place you can find their releases are on GH, not even
on dev.g.o.

> > * CI runs (e.g. GH actions)
> 
> I don't object to this and free CPU is free CPU. I just wouldn't want to
> create binary artefacts from it, but I don't think you're proposing that.

i would never trust such artifacts in the first place.  it's begging for
supply chain abuse.

> > * Projects for task management
> 
> I struggle with this a bit more because it'd hurt archeology efforts
> if GitHub got wiped.

i agree, although i note that exact situation occurs now _a lot_ because we
accept PRs and a ton of conversation happens there.  so if we ever migrate
off of GH, any migration process presumably would already have to compensate
for moving metadata.

> > * 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.
> 
> I'm not opposed to this if it's just for user support / queries rather than
> Bugs. Making it easier for people to seek help isn't a bad thing.

right, bugs belong on bugs.g.o.
-mike

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

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

[Ulrich Mueller]

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

>>>>> On Fri, 01 Apr 2022, Sam James wrote:

> We do need a proper solution in infra for hosting resources though.
> I thought we had a bug for it but I can't find it right this second,

I believe you're looking for bug 176186.
https://bugs.gentoo.org/176186

> bu the idea would be to expand projects.gentoo.org to more easily host
> distfiles and stuff independently of individual developers (whose
> links go dead when they retire).

Ulrich

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

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

[Andreas K. Huettel]

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

> We do need a proper solution in infra for hosting resources though. I thought
> we had a bug for it but I can't find it right this second, bu the idea would be to expand
> projects.gentoo.org to more easily host distfiles and stuff independently of
> individual developers (whose links go dead when they retire).

I hope you haven't set a minimum bug number in your query...


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

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

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

[Matt Turner]

On Tue, Mar 29, 2022, 10:56 AM Mike Frysinger <vapier@gentoo.org> 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.
>
> * release management (e.g. distfiles hosting)
> * CI runs (e.g. GH actions)
> * Projects for task management
> * 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.
>
> 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.
> -mike

What projects would you want to take advantage of these GitHub features?

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

[Luca Barbato]

On 29/03/22 19:56, 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.
> 
> * release management (e.g. distfiles hosting)
> * CI runs (e.g. GH actions)
> * Projects for task management
> * 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.
> 

Gitlab works fairly neatly at least in my experience with VideoLan, 
freedesktop and Gnome.

I'd avoid to bind ourselves too much on GitHub.

lu