@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 At the same time, tendency to reject is important to take note of, and "large project reasons" are not the major thing I took away here.


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