10
submitted 7 months ago by self@awful.systems to c/freeasm@awful.systems

reply with features and bug fixes you'd like to see in Philthy, the lemmy fork that runs on this instance. no guarantees I'll get to any of them soon, but particularly low-hanging fruit and well-liked features can be prioritized.

you are viewing a single comment's thread
view the rest of the comments
[-] froztbyte@awful.systems 3 points 7 months ago

repo and docs renames (I believe these have been done)

so, taking a look at this (because it seems like a good one with which to dive into the repo and gain a broader familiarity/see all the pieces), quite a bunch of places all across the source and docs that mention lemmy and use lemmy in element/crate/resource names:

❯ rg -icI lemmy | numsum; rg -il lemmy | wc -l
3741
411

tackling it would be best in stages, I think. both because in general I'm not a big fan of gigantic branches (being a complete pain to review, and absent really really good testing it's easy for things to slip through), and because that's just this repo even

for a staged rename of things, probably makes sense to try tackle subsystems one at a time? would we want to tag versions for each stage completion?

[-] froztbyte@awful.systems 3 points 7 months ago

even just looking at the list of places the name got used... oof. some deeeeeeply baked assumptions in here

[-] dgerard@awful.systems 3 points 7 months ago

i mean, lib names and so on is fine really

[-] froztbyte@awful.systems 3 points 7 months ago

I was thinking more the models and such

[-] self@awful.systems 3 points 7 months ago

I want to hold off on this for a bit since it will impact our ability to grab commits from upstream; for now I’d recommend we keep lemmy as a legacy symbol and use philthy in new development. once we’re in a good place for this, I imagine it makes sense to do it in stages, in an outside-in pattern — that is, we’d start by renaming things like the executable that’s very visible but breaks relatively little, then gradually make more internal, breaking changes

[-] froztbyte@awful.systems 3 points 7 months ago

that's a fair point too. will probably take a little while to find/develop some patterns for do now vs do later

this post was submitted on 12 Apr 2024
10 points (100.0% liked)

FreeAssembly

75 readers
1 users here now

this is FreeAssembly, a non-toxic design, programming, and art collective. post your share-alike (CC SA, GPL, BSD, or similar) projects here! collaboration is welcome, and mutual education is too.

in brief, this community is the awful.systems answer to Hacker News. read this article for a solid summary of why having a less toxic collaborative community is important from a technical standpoint in addition to a social one.

some posting guidelines apply in addition to the typical awful.systems stuff:

(logo credit, with modifications by @dgerard@awful.systems)

founded 7 months ago
MODERATORS