On 1:59 PM, Rene Rivera wrote:
[...]
Instead of all the criteria, I say throw it wide open. See who shows up, and what they accomplish. Let the cream rise to the top. (Again, you're not granting SVN access.) Having a big pool of volunteers you can call on to grind out the things many people can do seems very valuable.
The problem I see is that funneling through a small pipeline of maintainers that do the commits doesn't solve the problem of getting patches applied. It just prolongs the current bottlenecks to a different set of people. And I would hate to be one of those people given the likely huge workload in doing the commits. The most likely outcome of such a structure would be either: patches slowing to a crawl like now as maintainers don't have the time, or all patches get accepted as maintainers are overwhelmed and avoid doing full reviews. Neither of which is a desired outcome.
My original topic precisely. The bottleneck now is the maintainers getting their mind around each and every patch (or bug report, and coming up with their own patch). If that switches to a quick sanity-check and commit, I'd think a maintainer could knock them out pretty fast. Would chaos and confusion reign? Or would the risk of embarrassment cause guild members to act with great care? (Guild members, not submitters, mind you: They were motivated enough to sign up, and they can simply not submit anything they're not confident will work.) There will surely be bumps along the way. But if the trunk regression matrix were much greener than it is, that would show problems faster, too. I also envision us whipping up a little script that compares a regression to its previous one, showing newly-broken tests or symptom changes. (Does this already exist?)