Deal with abandoned mods #3960

Open
opened 2023-03-08 23:37:36 +00:00 by AliasAlreadyTaken · 10 comments

This issue shall find a solution to the problem of abandoned mods. The discussion originated in #3277 and the first victim is xocean.

This issue shall find a solution to the problem of abandoned mods. The discussion originated in #3277 and the first victim is xocean.
AliasAlreadyTaken added the
1. kind/protocol
1. kind/other
labels 2023-03-08 23:38:01 +00:00
Member

some other candidates with outstanding upstream PRs:

we also need to decide what to do w/ whosit's mods. i could write the code from scratch, but i don't want to deal w/ the graphics/formspecs. probably we can continue to use them, but distributing them is a different issue.

some other candidates with outstanding upstream PRs: * https://github.com/archfan7411/minetest-envelopes/ * https://github.com/minetest-mods/crafting_bench/ * https://github.com/GreenXenith/shared/ * https://github.com/pyrollo/display_modpack/ * https://github.com/AFCMS/mesecons_onlinedetector we also need to decide what to do w/ whosit's mods. i could write the code from scratch, but i don't want to deal w/ the graphics/formspecs. probably we can continue to use them, but distributing them is a different issue. * https://gitea.your-land.de/whosit/waypoint_announce * https://gitea.your-land.de/whosit/waypoint_compass
Author
Owner

I feel like its a bad idea to keep all of them in the super secret your-land orga, since they'll be in there anyways, but with a yl_stable branch we may not want to publish all the time. Maybe we should create another orga, where house all the abandoned mods, then treat this orga the same way we treat the mt-mirror account.

How about we call it "MT Orphanage" or "The ultimate Totally Real Upstream"?

Since it was a stupid decision to gather all the mirrored mods in an ACCOUNT instead of an orga, we could solve both problems with one orga? Password sharing aside, only one person has access to an "account", but multiple people can be added to an orga.

A mod cannot be "mirrored from upstream" and "abandoned" at the same time. Should a mirrored mod become abandoned, we simply need to disable the mirroring pull.

It's the other way round if we want to publish a yl mod: We can simply move the main branch to the public orga and don't have to deal with yl_stable leaks.

We could make this orga public and invite others. Stretch goal: replace github.

I feel like its a bad idea to keep all of them in the super secret your-land orga, since they'll be in there anyways, but with a yl_stable branch we may not want to publish all the time. Maybe we should create another orga, where house all the abandoned mods, then treat this orga the same way we treat the mt-mirror account. How about we call it "MT Orphanage" or "The ultimate Totally Real Upstream"? Since it was a stupid decision to gather all the mirrored mods in an ACCOUNT instead of an orga, we could solve both problems with one orga? Password sharing aside, only one person has access to an "account", but multiple people can be added to an orga. A mod cannot be "mirrored from upstream" and "abandoned" at the same time. Should a mirrored mod become abandoned, we simply need to disable the mirroring pull. It's the other way round if we want to publish a yl mod: We can simply move the main branch to the public orga and don't have to deal with yl_stable leaks. We could make this orga public and invite others. Stretch goal: replace github.
Author
Owner
https://gitea.your-land.de/your-land/administration/issues/180
Member

I feel like its a bad idea to keep all of them in the super secret your-land orga

i'm certainly not proposing to keep anything other than whosit's mods private. i always understood your intention was to to publish everything. however, it's certainly reasonable to keep some code (e.g. stuff in yl_events) secret for the time being.

Stretch goal: replace github.

minetest mod development is already spread across at least half a dozen public repo servers and an important few that don't allow creation of issues or PRs. gitea.your-land is already more than usable enough to serve as a hub for mod development.


side note:

orga

is that a german term? i think in english we'd just cal it an org (plural orgs). i think i know what you mean, just double-checking.

> I feel like its a bad idea to keep all of them in the super secret your-land orga i'm certainly not proposing to keep anything other than whosit's mods private. i always understood your intention was to to publish everything. however, it's certainly reasonable to keep some code (e.g. stuff in yl_events) secret for the time being. > Stretch goal: replace github. minetest mod development is already spread across at least half a dozen public repo servers and an important few that don't allow creation of issues or PRs. gitea.your-land is already more than usable enough to serve as a hub for mod development. ---------------- side note: > orga is that a german term? i think in english we'd just cal it an org (plural orgs). i think i know what you mean, just double-checking.
Member

I've added an MIT license to my code.
b73747bee4
ffd618cee0
If you have any other suggestions, please let me know.

I've added an MIT license to my code. https://gitea.your-land.de/whosit/waypoint_announce/commit/b73747bee48de8bb1ad8f0b7350241984b0ae688 https://gitea.your-land.de/whosit/waypoint_compass/commit/ffd618cee0fa793a4fbab4cdd4f6f64044c4d82e If you have any other suggestions, please let me know.
Author
Owner

We're pretty happy you're back, least of all due to licensing :D

We're pretty happy you're back, least of all due to licensing :D
Collaborator

display_modpack has a new unofficial repo: https://github.com/mt-mods/display_modpack

display_modpack has a new unofficial repo: https://github.com/mt-mods/display_modpack
Member

display_modpack has a new unofficial repo: https://github.com/mt-mods/display_modpack

thank you so much @Niklp! :)

> display_modpack has a new unofficial repo: https://github.com/mt-mods/display_modpack thank you so much @Niklp! :)
Member

hm how custom is our own fork of display_modpack? i worry about this: #157

hm how custom is our *own* fork of display_modpack? i worry about this: https://gitea.your-land.de/your-land/bugtracker/issues/157
Author
Owner

We're following upstream without any changes so far.

#157 was fixed by Atlante, their fix was then requested by Niklp to be moved from the YL repo to upstream. After that happened we switched upstream. Now upstream changed again and we'll follow that, too.

Niklp seems to have taken it upon them to fix a lot of longstanding bugs in legacy mods. Read: THX :)

We're following upstream without any changes so far. #157 was fixed by Atlante, their fix was then requested by Niklp to be moved from the YL repo to upstream. After that happened we switched upstream. Now upstream changed again and we'll follow that, too. Niklp seems to have taken it upon them to fix a lot of longstanding bugs in legacy mods. Read: THX :)
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: your-land/bugtracker#3960
No description provided.