Re: [boost] Respecting a projects toolchain decisions

Subject: Re: [boost] Respecting a projects toolchain decisions
From: Jim Bell (Jim_at_[hidden])
Date: 2010-12-28 01:33:49

On 1:59 PM, John Maddock wrote:
>>> Right, but then as I mention in a different thread, the
>>> maintainer/owner
>>> of the library can be MIA, and then I can ask the release managers
>>> and/or someone else who can pull the changes into their repository
>>> and shepherd the changes in. People (or in this case,
>>> I) can keep innovating and then the changes can get into the
>>> release in a less centralized manner -- which is the whole point
>>> of a decentralized system.
>>
>> [...]
>> Anyway, it seemed to me that the issue with patches for Boost.Pool
>> and Boost.Iterators wasn't any inability to supply the patches to the
>> 'official' place... it was an inability to get the attention of those
>> who had the power to get the patches into 'official' Boost.  Git
>> won't change that.
>
> I'm mostly staying out of this... but that sounds about right to me...
> at least we have a centralized place to put patches/bug
> reports/feature requests, what we really need is more folks to process
> them.

That's Boost.Guild's concept. See
<http://jc-bell.com/contributions/boost-guild>

>
> Further in order to process patches into the "official" release, we
> really need "that one guy" that just knows lib X inside out and can
> look at a patch and just know whether it's going to be OK or not.  I'd
> say about 3/4 of the patches I get are spot on, and frankly I never
> fail to be impressed by the quality of a lot of them.  But there's
> about a quarter that are either down right dangerous, or at least will
> cause more trouble down the line if applied.  Often these problem
> patches aren't obviously problems, it's just that the person supplying
> them quite clearly doesn't have the time to really get to know the
> library inside out, so they can be supplied by perfectly trustworthy
> individuals.  Hell, I may have submitted a few myself!  Too many
> patches like that, and the whole thing can snowball, making it much
> harder to fix things properly down the road.

This is the rub. Boost.Guild ticket handlers
<http://jc-bell.com/contributions/boost-guild/boost-ticket-handling>
seem like the best bet, if new maintainers don't step up.

>
> On the issue of library maintainers.... we don't actually need
> permanent full time maintainers for a lot of the older stuff... all
> they may need is a good spruce up every 5 years or so, with maybe the
> odd patch applied here and there in-between if there's a new compiler
> that causes issues.  Maybe as well as bug sprints, we should organize
> a few "hit squads" to go after an older library, rejuvenate it and
> then move on to the next target.

I hadn't thought of roving "hit squads" but I like it. My thinking: some
low level of continuous activity by a reasonably large group of people,
each doing a little: fixing regressions, closing tickets.

>   In fact if folks think that might be a good idea, I might be moved
> to try and organize something....

Please do! Can I interest you in the Guild? Want to refine it? Run it?