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
>>> 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
That's Boost.Guild's concept. See
> 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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk