From: Mike Frysinger <vapier@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 00:17:25 -0400 [thread overview]
Message-ID: <YkZ81dkvhicX56/S@vapier> (raw)
In-Reply-To: <0D733E18-F6C4-4235-AFA4-495A23B242FB@gentoo.org>
[-- 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 --]
next prev parent reply other threads:[~2022-04-01 4:17 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
2022-04-01 1:28 ` Sam James
2022-04-01 4:29 ` Mike Frysinger
2022-04-01 4:17 ` Mike Frysinger [this message]
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=YkZ81dkvhicX56/S@vapier \
--to=vapier@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