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

Subject: Re: [boost] [Guild] Getting volunteers' changes back to trunk
From: David Abrahams (dave_at_[hidden])
Date: 2010-11-14 17:26:58

At Sun, 14 Nov 2010 11:41:27 -0600, Rene Rivera wrote:
> 
> On 11/12/2010 9:33 PM, David Abrahams wrote:
> > At Fri, 12 Nov 2010 16:33:38 -0800,
> > Robert Ramey wrote:
> >>
> >>> 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.
> >
> > I think I understand what you're driving at, but if what you said were
> > strictly true, there would be no working partnerships in the world,
> > right?  There is such a thing as shared responsibility.  However, it's
> > true that you probably can't spread it uniformly across the community.
> 
> I don't think either Jim or myself have suggested fully spreading it
> across the community. 

I didn't mean to imply that you had.

> I think we both are suggesting "training" a group of volunteers, the
> Guild, to shared that responsibility. In exchange for healthier
> libraries we are trading some control. Which seems like a more than
> fair trade to me. What Jim and I are trying to grapple with is how
> much control is given up and how to temper the lost control. But
> what I mentioned in another response is that the goal would be to
> never loose control over the design. Since it's only patches to fix
> bugs that we are loosing some control over. And after all, it's the
> design that of paramount importance.

Implementation quality, documentation, maintainability, and other
factors are important too.  I'm reluctant to accept that there's an
absolute ordering.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com