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.
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.
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
lemmyin element/crate/resource names:❯ rg -icI lemmy | numsum; rg -il lemmy | wc -l 3741 411tackling 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?
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
lemmyas a legacy symbol and usephilthyin 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 changesthat’s a fair point too. will probably take a little while to find/develop some patterns for do now vs do later
even just looking at the list of places the name got used… oof. some deeeeeeply baked assumptions in here
i mean, lib names and so on is fine really
I was thinking more the models and such