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

Subject: Re: [boost] [Guild] Getting volunteers' changes back to trunk
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2010-11-12 11:34:33

On 11/12/2010 5:41 AM, Jim Bell wrote:
> On 1:59 PM, David Abrahams wrote:
>> At Sat, 06 Nov 2010 08:55:31 -0500,
>> Jim Bell wrote:
>>
>>    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.

I don't agree.. We keep promoting library authors to not be part of the 
Boost community this way. Library authors should accept that once their 
library is accepted other people in the community will help to maintain 
*all* of Boost not some sub-Boost. Otherwise we keep having the same 
problem of having libraries that are not maintained to users 
satisfaction because the owner is too busy. Once a Boost library is 
accepted it should become a shared responsibility of the community!

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

I disagree, the responsibility of getting verifying, applying, and 
merging should be shared. Again for the same reasons of Boost being a 
product of the community. I outlined some procedures for handling this, 
and allowing trust to build for people, including volunteers, doing this 
validation. But I guess no one liked my ideas, since no one responded. 
Oh, well.

>>> 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.

Trac supports custom workflows. So we can adapt it to handle whatever we 
want in the natural Trac way instead of a kludged tagged protocol.

> Should there be a guild mailing list?

Probably, just like we have a testing list for people volunteering 
testing resources. But, as you know, there must still be some fair 
amount of communications on the dev list. As that's what the core 
community will be paying attention to.

NOTE: The parts I agree with are cut ;-)

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail