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

Subject: Re: [boost] [Guild] Getting volunteers' changes back to trunk
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-11-12 19:33:38

David Abrahams wrote:
> First things first: I want to call this program "Boost.Guild." Agreed?
>
> 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.  We'll need a
> list of libraries whose maintainers authorize such changes, and
> libraries whose maintainers want to control all changes themselves.
>
>> What's the best way for the volunteers to signal to these
>> trunk-authority people to pick up their change?

modifying the ticket seems to work well - assuming there's an active
maintainer.

>> A Ticket keyword and corresponding report should work. Is there a
>> better way?
>
> I can't think of one.

> I don't think the volunteers themselves can be authorized to commit to
> trunk.  We need more trusted people to do that.

I would like to clarify this.  It's not a question of trust, it's more a 
question
realizing that there has to be one person who is responsable for the 
integrity
of the whole library.  In a larger library, many patches and fixes will 
inadvertantly
break something else.  If you want someone to be responsable, he has has to
have the authority to control all the changes.  If changes go in from more 
than
one person - then no one is responsable.

It seems to me that the real problem here is that some libraries are not 
being
maintained well enough.  I realize that this is not easy to fix, but you 
won't
make of for the lack of a person willing to be responsable for a library by
spreading the authority among another group of people.

The longer term solution is for boost to be more dynamic and decoupled
so that unmaintained libraries eventually can get dropped without creating
another fiasco.  I also admit that this doesn't help things right now but
there it is.

Robert Ramey