Wuzzy wrote:
This project sounds interesting, but I am not sure what to think about it.
I'll attempt to answer each of your questions, however, you ask quite a few, so if I miss a particular one, please repeat.
Wuzzy wrote:
So, how does this work, exactly? Do you accept just any mod which is compliant to license stuff or are there certain quality requirements? Which kind of mod would not be accepted?
I usually end up talking to mod developers before they contribute a mod. Most of them are very resistant to contributing beta-grade code, and therefore we don't see mods that are just not ready yet - almost all the mods are of decent quality, or better.
We've refused only a single mod at this point. The mod in question would be best described as "an experiment to see how much damage mod code could do", and therefore it fell squarely outside of the requirement that the mod should be of quality, since it had none, effectively, to serious potential users of the mod.
Anything closed-source is a no-go, from my perspective, as well. But that isn't really an issue due to the way github works.
Wuzzy wrote:
Also, how would you handle mods which provide conflicting APIs to solve the same problem? Would you include both? Just one? None? And which one?
At this point it's a non-issue and we don't see actual conflicts. I can see that we may have conflicts in the future, and I'll attempt to actually work with people to iron out the details (e.g. favor a component approach and break up more complex mods so both can exist as one being dependent, etc.). Most mod developers do not want to maintain code that is duplicated and better implemented elsewhere.
Nonetheless this may arise. I'm not the person who should decide which implementation is favorable (although I will certainly proclaim my opinion if I think it's needed), but ultimately both implementations can live in minetest-mods. Time will ultimately tell which one ends up being used or well-maintained.
I've written down however that we may end up refusing mods for this reason, and I think it's good to understand that mod writers shouldn't carelessly reimplement mechanisms, and we may want to discourage that. While I think we won't need to use or apply that particular rule, it may come in handy in case people are unwilling to modify API conflicts and other implementations are - in that case we have a reason to collectively decide to apply it.
Wuzzy wrote:
How is your repository going to solve mod fragmentation? If I see correctly, you are simply limiting the set of all mods to a subset of mods in your repo. The thing is, mod fragmentation does not magically disappear if you just make a repo. Or how exactly have you imagined to solve the fragmentation problem?
My best example of fragmentation is "carts". The original author isn't taking patches, there are 2 forks, but if you google for carts or do some forum searches, you will have a hard time finding that there are forks, and which one is better.
Just having a carts mod under minetest-mods would remove this problem entirely - the forked mods' authors could collaborate there on the original codebase if they wish, as long as pilzadam agrees to submit the project to minetest-mods. I've asked him, but, no reply.
The forks of 'carts' are likely to go exactly down the same route in the future - they were made out of frustration, and now they are not getting the right users or users won't even find their versions, etc.. It's a disaster.
Wuzzy wrote:
Also, I'd argue it will be increasingly harder to “legally” add a mod to the repo since one requirement states that no mod in the repo may conflict with another one. This means that mods which managed to get in early had good luck whereas newer, perhaps better mods might have a hard time to get in. I can foresee that bad things happen as soon as the first mob mod is added because the current situation with mob mods is a big fucking mess. xD
Also, do you plan to remove mods from the repo in favor of another (better) one?
I'm thinking you're taking the "conflict" too literal. I'm certainly not going to rigorously apply it, especially if mod writers maintain warnings that their mod conflicts with other mods, and have good reasons to do so.
What I am concerned about is if mods are conflicting with large amounts of other mods by breaking interfaces and commonly used functions, such as incompatibly implementing a core.* function override that breaks other mods.
Now, if mod writers work with us we can get those issues addressed.
Yesterday I loaded a minetestserver with ALL the 45 currently listed mods. None of them conflicted. A few did have overlapping or even duplicate functionality, but nothing broke, so, they're all good to go.
Wuzzy wrote:
Also, have people other than the original author already worked on mods (which seems to be the main motivation behind this project)? Can you point me to some examples?
I've been looking at statistics a bit, and I can't find easy ways to list what you want, but there are some good viewpoints you can use through github searches that list relevant aspects.
One page I visit daily is this: https://github.com/search?utf8=%E2%9C%93&q=user%3Aminetest-mods+is%3Aopen&type=Issues&ref=searchresults
it lists open PR's and Issues. As you can see there are a few PRs pending, most if not all are from non-authors.
Similarly: search github for: "user:minetest-mods is:closed is:pr" and you'll see quite the list of PRs, most by non-authors. Some may have been done before the projects were moved, but it should give you an idea.
Wuzzy wrote:
I am interested to see how this project works in real life (not just in theory).
Well, I'm impressed by the amount of mods at this point. However, I have to spend some more time convincing the more popular mods to make the move: mesecons, technic, moretrees/homedecor, pipeworks. With them in the group I think we can make a huge, huge difference.
Statistics: Posted by sofar — Thu Mar 10, 2016 03:36