@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 😅
chaos.social – a Fediverse instance for & by the Chaos community