This might feel true, but both academics who study software engineering and people who manage software projects for large, medium, and small teams will all tell you that it's very rarely borne out by experiment. In practice, the sort of "must check first" approach to multi-person software creation leads to some combination of massive overhead, ossification, cover-your-ass behavior, and deteriorating team dynamics. It works in small, tightly-knit groups with a high degree of both on-topic and incidental interaction, and basically doesn't work otherwise*. In a widely distributed volunteer group like most multi-person free software communities, you either have a BDFL, you trust your developers to use their judgement (including occasionally being wrong and recovering), or your project atrophies.

In this case, Lars was exactly right:

That said, it's fine for people to say something semantically like "I think we might be getting a little too loose with big changes on the bleeding edge. Maybe we should use feature branches more often?". It's possible that that's the exact sentiment that people are trying to express, but the realities of email lists creates a wide gulf between the above expression and "why are these things changed without doing some rudimentary query of users?".

I hope this helps, and doesn't just add to the noise.

~Chad

* I've seen this reported by people including researchers at MIT; at large companies like Amazon, Boeing, Google, IBM, and Microsoft; at medium-sized companies like Oracle (back when their software teams were medium-sized), Cygnus, and Red Hat, and at companies so small that nobody should recognize their names. If you're interested in the topic, I suggest Fred Brooks' _Mythical Man-Month_ as a baseline, and his _The Design of Design_ for a follow-up, as well as _Peopleware: Productive Projects and Teams_. (Caveat: it's been a while since I studied this, so there are probably more recent sources available.)