Mbin: a federated content aggregator, voting, discussion and microblogging platform (By the community, for the community) - GitHub - MbinOrg/mbin: Mbin: a federated content aggregator, voting, disc...
Ernest has some big life stuff going on right now (you can check out his posts if you really need to know), and hasn’t been able to review/merge in PRs for kbin lately. Furthermore, kbin.social doesn’t even have the latest changes that are merged in, so the community fork mbin was made by @melroy, one of the most prolific contributors to kbin.
Thank you for providing some context for this. It kind of sounds like a fork might not have been necessary if Ernest was willing to make @melroy a maintainer. Do you know if there’s any philosophical reason he wasn’t willing to do that? Real life stuff comes and goes, but it seems silly to halt the “official” project that others are relying on and still wanting to improve upon and thereby force a fork. As it stands right now, it sounds like it will be awkward for Ernest to come back in and try to restart work on kbin and will be increasingly awkward the more that mbin progresses, becomes the standard, and the code bases diverge.
Despite being maintainer of Kbin (incl. several others), we wasn’t allowed to merge other PR changes except my own or changes that Ernest didn’t like (eg. GUI pull requests were reverted again). Then when development slowly became to a halt, I didn’t want the project to die. I didn’t saw any other solution than to fork the project. Not only that, we also didn’t like some changes from the past, which Mbin also rolled-back (like only show local magazines in the random sectors in the sidebar).
The fork by the community for the community also allows us to do multiple things from the start: 1. No single maintainer anymore. 2. Introducing a C4 contract: https://rfc.zeromq.org/spec/44/ 3. More transparency and giving all contributors owner rights on all platforms incl but not limited by GitHub, Weblate and Matrix. Allowing multiple people to become fully responsible for the project. Having discussions about contents, when we as a community agree on changes PRs can be merged after 1 owner approval. Various instances now moved to Mbin (like https://fedia.io/ ), because they saw hope again. As stated earlier, we also moved to GitHub now and to the hosted weblate.org instance. Currently the development is booming, because it’s not getting reversed and slowed down.
We had ~150 PRs in a only 2 weeks time (Kbin has this number over a year not a week or two). The amount of improvements in the code, bug fixes, GUI, docker setup, documentation and security fixes as well as various features are impressive. Mbin is not about me, it’s about the community now.
Wondering why a move from Codeberg (non-profit, free software, self-hostable) to Github (propietary software, Microsoft)? Seems like Codeberg would be more aligned to the project’s values.
I agree but the reason was simple. Codeberg.org had too many down time issues. I and the community was impacted by the codeberg issues on almost a weekly basis. Hence the reason to move. I could also go to gitlab, but to keep reusing the Forgejo runners, github has the same workflow syntax. Anyhow, it’s also not up to me anymore. If the community decides to move to another git server I’m also fine with that. But I doubt the community want 5o move back to codeberg.
In retrospective, it’s a practical decision to move away from downtimes, especially seeing as development is so rapid now.
We might do a mirror to Codeberg to avoid a complete dependency on GitHub, while accepting PRs on the side. Priorities tell us to postpone this idea in favor of long-awaited changes and fixes, though! 😉
I was trying to setup multiple mirrors for myself as well, but both Codeberg and even sr.ht (sourcehut) makes it hard to just setup a simple mirror… Why do they make it so hard? I now just went for GitLab instead (https://gitlab.melroy.org/melroy/mbin which is now a mirror at least). But even then, it required GitLab Premium to have a repo pull mirror, luckily I have my solution for that: https://blog.melroy.org/2021/gitlab-pull-from-remote-repo/
Ernest has some big life stuff going on right now (you can check out his posts if you really need to know), and hasn’t been able to review/merge in PRs for kbin lately. Furthermore, kbin.social doesn’t even have the latest changes that are merged in, so the community fork mbin was made by @melroy, one of the most prolific contributors to kbin.
Thank you for providing some context for this. It kind of sounds like a fork might not have been necessary if Ernest was willing to make @melroy a maintainer. Do you know if there’s any philosophical reason he wasn’t willing to do that? Real life stuff comes and goes, but it seems silly to halt the “official” project that others are relying on and still wanting to improve upon and thereby force a fork. As it stands right now, it sounds like it will be awkward for Ernest to come back in and try to restart work on kbin and will be increasingly awkward the more that mbin progresses, becomes the standard, and the code bases diverge.
Despite being maintainer of Kbin (incl. several others), we wasn’t allowed to merge other PR changes except my own or changes that Ernest didn’t like (eg. GUI pull requests were reverted again). Then when development slowly became to a halt, I didn’t want the project to die. I didn’t saw any other solution than to fork the project. Not only that, we also didn’t like some changes from the past, which Mbin also rolled-back (like only show local magazines in the random sectors in the sidebar).
The fork by the community for the community also allows us to do multiple things from the start: 1. No single maintainer anymore. 2. Introducing a C4 contract: https://rfc.zeromq.org/spec/44/ 3. More transparency and giving all contributors owner rights on all platforms incl but not limited by GitHub, Weblate and Matrix. Allowing multiple people to become fully responsible for the project. Having discussions about contents, when we as a community agree on changes PRs can be merged after 1 owner approval. Various instances now moved to Mbin (like https://fedia.io/ ), because they saw hope again. As stated earlier, we also moved to GitHub now and to the hosted weblate.org instance. Currently the development is booming, because it’s not getting reversed and slowed down.
We had ~150 PRs in a only 2 weeks time (Kbin has this number over a year not a week or two). The amount of improvements in the code, bug fixes, GUI, docker setup, documentation and security fixes as well as various features are impressive. Mbin is not about me, it’s about the community now.
See also: https://kbin.melroy.org/m/updates/t/55330/Mbin-is-born-Fork-of-kbin
Wondering why a move from Codeberg (non-profit, free software, self-hostable) to Github (propietary software, Microsoft)? Seems like Codeberg would be more aligned to the project’s values.
I agree but the reason was simple. Codeberg.org had too many down time issues. I and the community was impacted by the codeberg issues on almost a weekly basis. Hence the reason to move. I could also go to gitlab, but to keep reusing the Forgejo runners, github has the same workflow syntax. Anyhow, it’s also not up to me anymore. If the community decides to move to another git server I’m also fine with that. But I doubt the community want 5o move back to codeberg.
In retrospective, it’s a practical decision to move away from downtimes, especially seeing as development is so rapid now.
We might do a mirror to Codeberg to avoid a complete dependency on GitHub, while accepting PRs on the side. Priorities tell us to postpone this idea in favor of long-awaited changes and fixes, though! 😉
I was trying to setup multiple mirrors for myself as well, but both Codeberg and even sr.ht (sourcehut) makes it hard to just setup a simple mirror… Why do they make it so hard? I now just went for GitLab instead (https://gitlab.melroy.org/melroy/mbin which is now a mirror at least). But even then, it required GitLab Premium to have a repo pull mirror, luckily I have my solution for that: https://blog.melroy.org/2021/gitlab-pull-from-remote-repo/
I’ve been tossing around CI pipelines for my work just for mirroring because of the patch work of support that repos have right now …
Thank you for laying it all out there. It sounds like you’re doing it the right way 🙂
deleted by creator