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-14 09:39:31

On 1:59 PM, Robert Ramey wrote:
> David Abrahams 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.

I'd say this maps to the release managers. That group being small
matters, as you suggest.

>   In a larger library, many patches and fixes will inadvertantly
> break something else.  

Absolutely. To that end, a diff of every test matrix with the previous
one, in some form, would be very useful.

> If you want someone to be responsable, he has has to have the authority to control all the changes.  

But even the act of tracking down how recently libX/testY/platformZ
broke and what broke it is more work than one person can sort out.

> 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 [up] for the lack of a person willing to be responsable for a library by
> spreading the authority among another group of people.

I disagree. If a person signs onto a ticket, (s)he takes responsibility
for that ticket for its life, so (s)he'd get pulled into working out
things cascading from that ticket.

> 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 disagree. Perhaps a library would be frozen--no new features--because
of a lack of maintainers.  But, theoretically, once a regression test
works, it should keep working from now until the end of the universe.

And if it quits working (for a library that "hasn't changed"), why?
1. Another bug fix for that library broke it. (The guild member for that
fix gets involved.)
2. Breaking change in a dependency. (A good candidate for the guild to
handle.)
2. Language construct made obsolete, (Another good candidate.)
3. ??? [Chime in here.]

I suggest that the main barrier to fixing something that breaks isn't
that a library expert hasn't looked at it in sufficient depth, but that
NO ONE has looked at it.  Thus the guild.

Twenty minutes studying it, without any knowledge of the library's
internals, could fix many. For some, that could grow into a few hours,
but a guild member working at his own pace would knock it out.