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.
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.
seems like you are saying ernest put thru an intentionally malicious PR to see what would happen? And what happened was exactly what is described? I mean, ya, thats what people will do.
It wasn’t entirely intentional, it was actually my mistake. But I held off on pushing the hotfix for a while. It was a development branch, so these kinds of bugs were permissible - in this case, it just changed the order of related posts, nothing serious. It was quite easy to spot and fix. Slow and cautious acceptance of pull requests, something I spent a lot of time on, was the main accusation from the creators of forks. Hastily accepting them was a problem for me. I personally considered a consensus similar to that, but now I see it doesn’t make sense. Someone needs to take responsibility. Personally, I believe that forks are the best thing that could have happened to the project.
It is good to really see your true nature now. I’m also think the fork is the best thing that could have happened for the community. It’s a pity that you never started a conversation, but instead you still try to do mean things like this.
Oh c’mon, don’t be mad. It’s just a wrong sorting of posts, it’s in an edge case, and seriously it wasn’t intentional. I just wanted to check how such management looks in practice, how many merge accepts are needed, etc. I didn’t mean to do anything wrong that could cause harm. I even push the same code to my instance to facilitate your tests ;)
But you’re right - that’s just my nature. I approach PR with very limited trust, whether they’re mine or from others.
I know your approach on PRs. Hence the main reason of the fork. The community does believe in their people and the good in mankind. Only 1 approval is required from another maintainer for now. We are using C4 way of working.
I assure you that I didn’t intentionally push incorrect code into the repository. These were my first lines of code in a really long time. I simply got involved in other things that I wanted to finish first, and I noticed the edge case in the meantime, but it wasn’t a priority. I saw that you were syncing and I was hoping to benefit a bit from it once you fixed it. I didn’t expect the review to happen so quickly. By the way, I was genuinely curious about how this project management method works because, you know, I’ve always avoided such an approach. Merloy, you know how much I owe you, and I appreciate what you’ve done for the project, as well as the other Mbin contributors. Our overall visions haven’t always been the same, and I think it’s great that kbin has been forked. You see for yourself how my work looks until the release - there are many things I’ll be refining over time. That’s why I’ve put a hold on all other PRs, and now I want to focus on this.
“True nature” in this case appears to be slow and cautious. Shocking stuff!
In hindsight maybe we should have responded by saying we merged your mistake intentionally to see how you’d respond.
i am not being serious of course, as that’s not our community’s nature. Even though it’s allowed to gather proof, we (I am quite sure I can speak on behalf of the community here) would never intentionally introduce bad code into software which is being actively used.
Ernest, you have seen me before, pleading for you to change your ways, on all fronts. This, sadly, degrades the faith I have in your project being suitable for being used in production, from a pragmatic point of view. Kbin may be reliable, but you are not.
Ernest said he didn’t introduce bad code on purpose:
I assure you that I didn’t intentionally push incorrect code into the repository. These were my first lines of code in a really long time. I simply got involved in other things that I wanted to finish first, and I noticed the edge case in the meantime, but it wasn’t a priority.
Ernest has said many things in the past and many times has not lived up to his promises. So I doubt this words now. Also he’s already contradicted himself on this matter.
Yeah, that’s true. Real-life stuff was kinda more important for me at the moment than managing the project.
For me, it’s straightforward: I pushed some dev code that wasn’t even a complete feature, and it got approved in your pull request. That’s why I was advocating for everyone to only merged their own PRs in the /kbin repository – so that each person could take responsibility for their own work. I won’t go on about this any further.
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.
