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 06:41:23

On 1:59 PM, David Abrahams wrote:
> First things first: I want to call this program "Boost.Guild." Agreed?

Agreed. (I like it!)

> At Sat, 06 Nov 2010 08:55:31 -0500,
> Jim Bell wrote:
>
>> Say you have a team of volunteers attacking failed regressions and
>> tickets. They're creating (hopefully) good trunk patches. They can't
>> commit to the trunk, but can modify tickets.
>>
>> If maintainers are active, they could review and incorporate
>> them. But this increased activity may be more of a strain for
>> them. If maintainers are MIA, it won't happen.
>>
>> So we need at least one person to bring these changes back into the
>> trunk. Changes to libraries they're not familiar with.
> BoostPro is willing to commit resources to help with that if there's
> someone else (like you) running the program with us.

I envision it to be self-study and group-study. What do you see my role
being? (Besides keeping an e-mail list of members and organizing the
lavish annual appreciation banquet. ;-)

>   We'll need a
> list of libraries whose maintainers authorize such changes, and
> libraries whose maintainers want to control all changes themselves.

Agreed. I envision active maintainers establishing rapport with guild
members whose work they liked.

>> What's the best way for the volunteers to signal to these
>> trunk-authority people to pick up their change?
>>
>> A Ticket keyword and corresponding report should work. Is there a
>> better way?
> I can't think of one.
>
>> Should we look for a person or two from the volunteers for this
>> role?
> I don't think the volunteers themselves can be authorized to commit to
> trunk.  We need more trusted people to do that.

I agree. One trusted person should sanity-check marked changes and
merge. (And revert!) And a single person would be good in terms of
getting to know guild members whose work needs closer scrutiny. (And
they could ask other guild members to help with that scrutiny.)

But could this alone be a significant effort?

>> A regular schedule (say, twice a week) to run the report and patch
>> would be good, I think. Trunk regressions need time to bake.
> Sorry, which report?

A Trac ticket keyword query showing the trunk patches that guild members
suggest.

In fact, we could build a sophisticated guild workflow using trac ticket
keywords alone. I haven't decided if that's crazy or brilliant.

Should there be a guild mailing list?