Mbin: A kbin fork that promises to never review PRs before merging them
Mbin: A kbin fork that promises to never review PRs before merging them
Somebody who was previously active on the kbin codeberg repo has left that to make a fork of kbin called mbin.
repo: https://github.com/MbinOrg/mbin
In the readme it says:
Important: Mbin is focused on what the community wants, pull requests can be merged by any repo member. Discussions take place on Matrix then consensus has to be reached by the community. If approved by the community, no additional reviews are required on the PR. It's built entirely on trust.
As a person who hangs around in repos but isn't a developer that sounds totally insane. Couldn't someone easily slip malicious, or just bad, code in? Like you could just describe one cool feature but make a PR of something totally different. Obviously that could happen to any project at any time but my understanding of "code review" is to at least have some due diligence.
I don't think I would want to use any kind of software with a dev structure like this. Is it a normal way of doing stuff?
Is there something I'm missing that explains how this is not wildly irresponsible?
As for "consensus" every generation must read the classic The Tyranny of Stuctureless. Written about the feminist movement but its wisdom applies to all movements with libertarian (in the positive sense) tendencies. Those who do not are condemned to a life of drama, not liberation.
I agree, this is a wild reactionary shift to the issues they've seen with kbin. Unless the community "consensus" includes people actually reviewing and testing this is just going to put the repo admins in a tough situation when they have to merge in some broken commit the community voted on.
It looks like they're still working out what they want their process to be:
https://github.com/MbinOrg/mbin/pull/34
Seems like your concern is addressed there:
Pull Requests require at least one (1) other maintainer approval before the PR gets merged (built-in peer review process).
The mbin fork happened when kbin development was looking a lot less active. In any case, it's not necessarily bad to have a diversity of approaches. Due to their differing organizational structures, mbin will likely tend to have more features and more rapid development, but also potentially more bugs, while kbin remains more stable.
I cant follow the convo to tell if this is the actual state of things or just something thst was being discussed but:
16 Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.
What an idea.
From the PR comments:
Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.
I asked around and asked in the C4 specification matrix room.
And the reason is actually simple. If you merge bad code, have a record of proof in git (pull requests aren't forever it's only a github/gitlab thing).So the idea is if you merge bad code you have proof in the git record that there is a bad actor. You can always revert the commit again or fix it. And the record can act as a proof in case the community want to get rid of bad actors.
I think it’s an interesting experiment. If it survives natural human tendency to mess with things, then it could be a good process discovery that is further refined and implemented elsewhere.
I don’t have any reason to believe it’ll be a success, but that shouldn’t stop people from at least trying.
If it's any consolation, you likely won't have to worry about using it, as its liable to be unusable.
Sounds like it'll be a disaster
It seems to automatically pull all changes from kbin anyway so I don't know about this consensus approach.
Hmm, that seems like not such a good look from Ernest. According to google translate:
I know, honestly it was on purpose. I noticed that forks sync changes immediately with /kbin. I wanted to check how they deal with this much-announced community-based qualitative code review. Answer: they can't cope. Quite an obvious bug was accepted in PR and domerged into the main branch :P It now works properly on the rifle ;)
Hopefully everyone can play nice and work together productively.
I do love Mbin, I just wish we had an area instead of Matrix to talk about things that we want and stuff.
Thanks for your feedback.
We do have code reviews in GitHub and discussions on Matrix. We updated the README that reflect our latest way of working. As stated in the comment section we are also working on it in PR: https://github.com/MbinOrg/mbin/pull/34. Feel free to comment on that.
This early in a project, figuring out how to manage it effectively is a big part of the work, I think. There's no inevitability to either project failing or succeeding. I hope both projects do something cool, and if one fails I hope there are a few forks of it ready to carry on with the best parts of it.
As a person who hangs around in repos but isn't a developer that sounds totally insane.
Why do you hang around there then? So you can write articles like this in an attempt to stir the shit? What is there to gain from that, for the fediverse?
I'd also like to know how you hang out there then, as I can't seem to find a person called Density hanging around? I might not be looking in the right place, of course