For those who have been programming in Erlang since 16 years like me, you may remember the concept of , "a dense and chaotic jungle of Erlang code".
started in somewhat the same spirit a while. However, as ejabberd main code base is evolving at a very fast pace, we need to ensure that users do not lose time trying to make module that have not been updated to the latest version works.
ejabberd-contrib is now a curated repository of ejabberd modules. We have cleaned it up, fixed a few things and identified 5 modules that at the moment does not work.
That repository is now ready to gather your ejabberd contributions of all horizon, gather developer feedback and ready to make sure together that the code in there is always working fine.
There is plenty of very useful module in there and we will be gathering and selecting other relevant contributions from various developers ourselves.
However, you are very welcome to clone the repository and submit your pull request. As an ejabberd module developer, it's your place. You are welcome !
Here is the place to go:
ejabberd-contrib repository
The ejabberd-contrib repository still hosts most important modules. The repository goes back to the SVN days. That is still reflected in the large monolithic repository layout and the migration to git never took that into account. Module developers can no longer develop their own modules on their own but have to rely in p1-devs to merge the request.
The current layout does not match git well. The official git wiki splitting an SVN repository up into multiple repositories when moving to git. This is what most FOSS projects did, as far as I know. I think we should start doing the same here, with ejabberd.im keeping links to repositories with individual modules.
Quote: Module developers can
Module developers can no longer develop their own modules on their own but have to rely in p1-devs to merge the request.
I think those who are actually interested in further development of their modules should just ask for push access to the ejabberd-contrib repository. But in practice, the original authors often don't really provide long-term maintenance/support. So I think it's good to have a team take care of that.
The current layout does not match git well.
As I said in private chat, personally I wouldn't mind splitting up the repository, as long as the same team remains responsible. However, we'd have to figure out a good way of dealing with the infrastructure which is used by all modules and currently maintained in the
ejabberd-devdirectory of the repository.ejabberd-contrib repository
Hello,
You should more think about this repository as Homebrew. This is a way to have a large set of features for which the development is very open and almost integrated into ejabberd. This is the exact opposite of what you describe.
The goal is NOT to rely on ProcessOne to accept Pull requests, but to open largely the commit rights on that repository. Let me know if you want an account :)
ejabberd is already split into several repositories (p1_yaml, xml, etc). However, the approach of splitting module that can be a single file into its own repository as issues as well, the main one being discoverability.
Anyway, we can consider that split, but we need to find a way to make sure those contributions can be easily discoverable by ejabberd users.
Hello Mati, We listened. Our
Hello Mati,
We listened. Our new approach on ejabberd-contrib allow pointing to external repository, just holding a spec file in the main repo.
You can read more here: https://blog.process-one.net/easy-installer-and-structure-for-ejabberd-c...
I hope you will like it.