Re: [boost] [Guild] Getting volunteers' changes back to trunk

Subject: Re: [boost] [Guild] Getting volunteers' changes back to trunk
From: Jim Bell (Jim_at_[hidden])
Date: 2010-11-12 15:39:52

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?)