The Kbin developer wants to focus his work on deeper technical challenges, while the Mbin developers want development to be more fast-paced with greater community involvement. Both takes are valid, but difficult to combine in one development effort.
There is a saying that if civil engineers would build houses the same way as software engineers build software, the first woodpecker would destroy the whole civilization.
In reality it is not easy to build good software and it can be fragile even with good practices. This approach allows anyone’s code merged without much supervision.
Another thing is (and I even noticed myself doing it, even though normally I think of myself as perfectionist) is that when one contributes a feature to a project that they don’t maintain. They just think only about the feature and the easiest way of implementing it, which isn’t necessarily the best way to implement something long term, adding complexity, makes harder to add more features and much easier to accidentally create bugs.
Third, preventing security vulnerabilities is hard even with good practices, someone could accidentally (or purposely) introduce a security vulnerability.
As quality control is more relaxed, there’s fewer safeguards against potentially bad code (bugs or harmful stuff, intentional or non-intentional).
When there was a bit of friction between kbin and mbin, this was the starting point: kbinwas criticized for being too slow and conservative, taking ages to implement features because everything needed to be thoroughly thought through and it’s just one man doing that. Meanwhile mbin went pretty far out in the opposite extreme. Both found the approach of the other potentially harmful (by either discouraging contributors or by not having enough checks in place).
The Kbin developer wants to focus his work on deeper technical challenges, while the Mbin developers want development to be more fast-paced with greater community involvement. Both takes are valid, but difficult to combine in one development effort.
After I posted it, I found another discussion where it looks like mbin policy is that anyone can merge anyone else’s PR.
As a software developer, that actually sounds really scary.
how does it?
There is a saying that if civil engineers would build houses the same way as software engineers build software, the first woodpecker would destroy the whole civilization.
In reality it is not easy to build good software and it can be fragile even with good practices. This approach allows anyone’s code merged without much supervision.
Another thing is (and I even noticed myself doing it, even though normally I think of myself as perfectionist) is that when one contributes a feature to a project that they don’t maintain. They just think only about the feature and the easiest way of implementing it, which isn’t necessarily the best way to implement something long term, adding complexity, makes harder to add more features and much easier to accidentally create bugs.
Third, preventing security vulnerabilities is hard even with good practices, someone could accidentally (or purposely) introduce a security vulnerability.
As quality control is more relaxed, there’s fewer safeguards against potentially bad code (bugs or harmful stuff, intentional or non-intentional).
When there was a bit of friction between kbin and mbin, this was the starting point: kbinwas criticized for being too slow and conservative, taking ages to implement features because everything needed to be thoroughly thought through and it’s just one man doing that. Meanwhile mbin went pretty far out in the opposite extreme. Both found the approach of the other potentially harmful (by either discouraging contributors or by not having enough checks in place).
deleted by creator