Fork `basement`? As `baseplate`?

taylorfausak:

This is hardly the first time this situation has happened. Consider the xml library. It hasn’t been updated in over 10 years. Does someone deserve to take it over? I don’t think so.

ehh..well what if 1000s of packages relied on it transitively. And something happened (GHC evolution) that broke xml and now it needs some elbow grease. Now vanilla cabal just doesn’t work (and will never work ever again) for a huge part of the ecosystem. Everyone indirectly touching xml must now muck around with cabal.project or a Nix overlay or whatever stack uses for this sort of thing.

So then let’s say the maintainer is contacted and they say “nah I’m not gonna update it. nah I’m not gonna accept any PRs and push updates to Hackage. nah I’m not gonna hand over ownership or even allow someone else to have the commit/update bit in addition to me.”

then YES - that’s takeover time. xml is a good example here because it, like basement and memory, is a core building block other projects may stand on.

taylorfausak:

To me the only reasonable solution is to allow namespacing packages by the maintainer’s name. Then we could have @vincent/memory and @apotheca/memory without issue.

Namespacing is cool, but I don’t see how it would be functionally much different here than the whole “fork and rename” approach. The same toil would result - unless I’m missing smth.