@alexcleac This seems very not thought through. There’s very good reasons to reject a patch that improves one thing but is otherwise not in a good shape. Nothing is as permanent as a temporary hack, and once it works, the incentive to work on a better version isn’t there anymore. Yet the author claims every patch should be accepted unless it violates well-documented requirements. Even saying coding style should not be followed! I think this author never worked on larger projects in a large team.

@js I agree with you partially.

From my PoV, working software that works thanks to a hack >> not working software with perfect code. Thus hacky patch is better than blocking it when it does not follow explicit rules. I have worked on large teams, and this is the only way really huge projects can work in long term, but require good maintainers to keep things smooth.

@alexcleac The problem is if you accept any patch, even ignoring code style and everything, you end up with broken window syndrome.

@js I agree, but those requirements must be explicit and visible for any possible contributor

Redrafted: fixed typo, replying with phone 😅

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!