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.
this post was submitted on 09 Nov 2023
9 points (100.0% liked)
Fediverse
12 readers
1 users here now
This magazine is dedicated to discussions on the federated social networking ecosystem, which includes decentralized and open-source social media platforms. Whether you are a user, developer, or simply interested in the concept of decentralized social media, this is the place for you. Here you can share your knowledge, ask questions, and engage in discussions on topics such as the benefits and challenges of decentralized social media, new and existing federated platforms, and more. From the latest developments and trends to ethical considerations and the future of federated social media, this category covers a wide range of topics related to the Fediverse.
founded 2 years ago
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.
Sounds like it'll be a disaster
If it's any consolation, you likely won't have to worry about using it, as its liable to be unusable.
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.
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.
load more comments
(15 replies)
load more comments
(11 replies)
I do love Mbin, I just wish we had an area instead of Matrix to talk about things that we want and stuff.
I'm still not getting the point of mbin. I mean, options are nice, but what's the value it brings over kbin?
they don't use github issues?
They do but it would be nice to have a place to talk about it in a Magazine instead of having to go to external sites
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.
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
view more: next ›