Boost logo

Boost :

Subject: Re: [boost] Respecting a projects toolchain decisions
From: John Maddock (boost.regex_at_[hidden])
Date: 2010-12-27 13:14:25


>>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.
>
> It seems to me you could write almost the same thing using SVN-speak...
>
> "if the owner is MIA, I can send the patch to the release manager who can
> apply the patch to SVN and shepherd the changes in. That way I can keep
> innovating on my local working copy and the change can get into the
> release on its own schedule"
>
> 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.

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.

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. In fact
if folks think that might be a good idea, I might be moved to try and
organize something....

Just my 2c, John.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk