From: Sam James <sam@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] utilizing GH functionality that Gentoo infra does not provide
Date: Fri, 1 Apr 2022 02:27:00 +0100 [thread overview]
Message-ID: <0D733E18-F6C4-4235-AFA4-495A23B242FB@gentoo.org> (raw)
In-Reply-To: <YkNIOS5E7gSH1cOk@vapier>
[-- 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 --]
next prev parent reply other threads:[~2022-04-01 1:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 17:56 [gentoo-project] utilizing GH functionality that Gentoo infra does not provide Mike Frysinger
2022-03-29 18:26 ` Arthur Zamarin
2022-03-29 18:47 ` [gentoo-project] Gentoo's GitLab (was: utilizing GH functionality that Gentoo infra does not provide) Anna Vyalkova
2022-03-29 19:29 ` [gentoo-project] utilizing GH functionality that Gentoo infra does not provide Alec Warner
2022-03-31 2:01 ` Mike Frysinger
2022-03-29 19:36 ` Andreas K. Huettel
2022-03-31 2:01 ` Mike Frysinger
2022-03-31 8:21 ` David Seifert
2022-04-01 4:04 ` Mike Frysinger
2022-04-04 18:54 ` Andreas K. Huettel
2022-03-31 11:48 ` Maciej Barć
2022-03-31 16:43 ` Michael Jones
2022-03-31 18:07 ` Maciej Barć
2022-04-04 15:38 ` Andrew Ammerlaan
2022-04-01 1:27 ` Sam James [this message]
2022-04-01 1:28 ` Sam James
2022-04-01 4:29 ` Mike Frysinger
2022-04-01 4:17 ` Mike Frysinger
2022-04-01 5:52 ` Ulrich Mueller
2022-04-04 18:48 ` Andreas K. Huettel
2022-04-02 15:48 ` Matt Turner
2022-06-11 17:15 ` Luca Barbato
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0D733E18-F6C4-4235-AFA4-495A23B242FB@gentoo.org \
--to=sam@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox