<isd>
I'm kindof wanting to do some general API cleanup. The master branch has some changes to the connection setup APIs. And There are some places where I don't feel like you should need to pass a supervisor but you do.
<LyreCalliope[m]>
Here to help with some nontechnical community stuff!
<TimMc>
o/
yarmo0 is now known as yarmo
<fr33domlover>
isd: I'd make sure your soul gets to heaven lol
<fr33domlover>
isd: and now seriously: It would allow me to contribute indeed :) Idk if I'd have useful stuff to contribute, but I hope I would
<isd>
Alright. I may do that. I'm wondering if tempest marks a good time for me to start migrating stuff over in general. I think my thinking on moving away from GitHub 2-ish years ago was "when sandstorm can host it," but I think it's going to be long enough that getting away from GitHub in the short term is worth doing other ways
<ocdtrekkie>
I find GitHub strongly preferable for browsing/monitoring of things, mostly because ForgeFed hasn't happened yet.
<ocdtrekkie>
Codeberg has some sort of built-in mirroring capability though, IIRC?
<isd>
I'd have to investigate. Wouldn't mind continuing to mirror stuff if the overhead is sufficiently low
<isd>
But yeah, the networks are huge :/. I'd like to stop being part of the problem.
<isd>
For haskell-capnp at least, no-one else I care about seems to be following it/interacting with development, so we have 100% preference for codeberg :P
<isd>
(There are a bunch of stars, but meh)
<isd>
(nobody who talks to me)
<ocdtrekkie>
I use a GitHub Action to mirror to my Sandstorm server, but that is a choice to leave GitHub as the source of truth for the moment. Think you could do the same for Codeberg to GitHub, but probably would want to specify contributions should be sent via Codeberg then?
<ocdtrekkie>
I mostly care wrt to Tempest, personally.
<isd>
Yeah, could do something like that.
<isd>
You seemed to stay on top of it when it was just a gitweb grain :P
<ocdtrekkie>
Git being decentralized, I feel like we should treat it like that and try to push it many places instead of picking one.
<ocdtrekkie>
Yeah but I had to check it manually explicitly. It's much nicer in my usual feed now.
<isd>
Yeah, I just wish the issue tracker & prs and such were part of that.
<isd>
Clearly, this means we should switch to fossil /s
<ocdtrekkie>
Yeah, it isn't super clean but technically you can accept PRs and issues from multiple sources. But you probably would want to manually merge branches locally if not submitted via your site you are using as the source of truth.
<isd>
Yeah.
<ocdtrekkie>
Missed opportunity for issues to also be a git repo.
<ocdtrekkie>
Like I know the GitHub wiki feature is just another repo behind the scenes.
<isd>
Yeah, it's just a bunch of .md files. A bit harder to design for an issue tracker.
<isd>
It's definitely a project I've spent some time thinking about in the past.
<TimMc>
There are a bunch of approaches people have designed for putting issue tracking into git repos.
<TimMc>
But barring that, there's really no reason issues have to be tracked in the thing that's associated with the git web interface.
<TimMc>
I really do like GitHub's UI, though. They've done a pretty good job. No JS requirement for just poking through files, which is a bonus.
<ocdtrekkie>
I have contributed to a project on a Gitea server, but I felt like I was fighting the tools more than I am when on GitHub, at present. I'm all for moving the default away, but yeah, retaining the presence there I think holds value.