Gentoo Archives: gentoo-project

From: Sam James <sam@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] utilizing GH functionality that Gentoo infra does not provide
Date: Fri, 01 Apr 2022 01:27:12
Message-Id: 0D733E18-F6C4-4235-AFA4-495A23B242FB@gentoo.org
In Reply to: [gentoo-project] utilizing GH functionality that Gentoo infra does not provide by Mike Frysinger
1 > On 29 Mar 2022, at 18:56, Mike Frysinger <vapier@g.o> wrote:
2 >
3 > starting a dedicated thread for
4 > https://archives.gentoo.org/gentoo-project/message/ec2b560480627371a7bda5c85924eddd
5 >
6
7 Just as an introduction, I'd like to say I am deeply sympathetic to the need
8 to be practical and it's easily what I prioritise most. So I do get it.
9
10 > GH provides a lot of functionality for free that Gentoo infra does not cover.
11 > these are particularly useful for projects that are used beyond Gentoo.
12 >
13 > * release management (e.g. distfiles hosting)
14
15 I'm not sure I love this one under the test of "if our GH got wiped tomorrow, would there
16 be much impact?"
17
18 If downstream and others are using e.g. pax-utils with an unreliable SRC_URI,
19 that *is* a pain, and it's not much comfort to then tell them that it "wasn't
20 covered by infra anyway" or something.
21
22 We do need a proper solution in infra for hosting resources though. I thought
23 we had a bug for it but I can't find it right this second, bu the idea would be to expand
24 projects.gentoo.org to more easily host distfiles and stuff independently of
25 individual developers (whose links go dead when they retire).
26
27
28 > * CI runs (e.g. GH actions)
29
30 I don't object to this and free CPU is free CPU. I just wouldn't want to
31 create binary artefacts from it, but I don't think you're proposing that.
32
33 > * Projects for task management
34
35 I struggle with this a bit more because it'd hurt archeology efforts
36 if GitHub got wiped.
37
38 > * possibly even Discussions since it'll provide a clear/scoped space for
39 > non-Gentoo users & devs. Gentoo forums are huge and require custom accts,
40 > and mailing lists are huge and a bit restrictive old timey.
41 >
42
43 I'm not opposed to this if it's just for user support / queries rather than
44 Bugs. Making it easier for people to seek help isn't a bad thing.
45
46 > this is all orthogonal to the git content itself (objects, branches, tags,
47 > etc...). those should remain in the read-only clobber mode that exists now.
48 >
49 > there is no downside for Gentoo here. it's all functionality that can be
50 > had for free, does not introduce any risks, and many devs are already using
51 > GH heavily for Gentoo projects -- albeit, they don't do it under the Gentoo
52 > umbrella, they fork it into their own personal space and maintain it there.
53
54 Yep, and I'm guilty of this as well. I've started making a list of some important
55 repos we really need to mirror onto our infra at least (inc, but not limited to,
56 pkgcore).

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies