* <jpac...@redhat.com> [2013-10-24 10:33]: > > i've been maintainer of sufficiently many projects to know that this > > is not a universally true statement. a significant percentage of casual > > contributors throws some crappy code at you and expects you to be > > grateful for it, possibly flaming you down when you make no such > > pretenses. > > Of course, but they build only a minority and therefore if the others > don't like their work, why not to revert the commit or rewrite the patch > with prompting the original author that the patch was really bad?
This sounds so awesome! No need for maintainers. The community will just magically take over all their work. Of course, in practice, it doesn't work this way. Occasional contributors add their favourite feature or fix a bug they stumbled over. That's it. They provide patches, they don't do patch review. Maintainers do. They fix or reject code that's slow, insecure, duplicated, inconsistent, non-portable, undocumented, useless, badly designed, badly formatted, and so on. They reject features that are out of scope or duplicate existing functionality. They decide on controversial issues. These things require a level of motivation, knowledge, commitment, and authority that occasional contributors lack. Occasional contributors are good at taking care of issues that cause obvious harm to everyone immediately. The problem is that the negative effect of applying low-quality patches often doesn't become obvious until many such patches pile up, or just for some fraction of users. If the performance of reading a local mbox goes down by 2 percent, nobody will notice. When it went down by 20 percent, it might well be too late to fix the mess; at least for occasional contributors. It would've been the maintainer's job to make sure the 2 percent loss doesn't kreep in. If you just ditch the concept of long-term maintainers, you _will_ end up with more features, and with a lower-quality code base. So this is a trade-off, and your preference might differ from mine. But denying that we're talking about a trade-off seems like a highly unrealistic view to me. > What are you afraid of then? As far as I'm concerned, I'm afraid of having to pay too much for new features in terms of quality (e.g., stability, performance, saneness, and accuracy of documentation). > Of course, many "distro guys" are also highly interested and/or involved > in upstream development, but at the end, they anyway deliver what users > want. As a Mutt user, I'd expect both upstream and package maintainers to not blindly deliver whatever I want, but only those changes that seem feasible given the maintainer's knowledge (that I don't have). Holger
