Re: [boost] Respecting a projects toolchain decisions

Subject: Re: [boost] Respecting a projects toolchain decisions
From: Dave Abrahams (dave_at_[hidden])
Date: 2010-12-28 21:03:56

At Mon, 27 Dec 2010 18:14:25 -0000,
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.
> >
> > 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.

I think this is where the "web of trust" comes into play.  One problem
right now is that for each library there's a single bottleneck through
which all changes *must* pass.  No release manager is going to
integrate changes from an outside contributor without them having been
looked over by the library maintainer.  Heck, patches don't even get
*tested* in a meaningful way until the library maintainer has pulled
them in.  If patches could be broadly tested, I can easily imagine
that a community contributor's level of credibility could rise to a
level where her patches would be accepted upstream very easily without
intervention.  It's also the case that merging changes and moving them
to the release branch is just *way* too labor-intensive to make broad
contribution practical.

Take a look at GitHub for example.  After you develop changes in your
own repo, you can issue a "pull request."  Here's a project with a
bunch of those pull requests pending:
https://github.com/dimitri/el-get/pulls The maintainer can easily
review the changes, and the site will tell the maintainer which of the
changes are going to merge cleanly.  Then he can press a button and
the merge is done.  If I had something like that for Boost.Python, I
promise you I'd be processing a lot of those patches that are right
now idling in Trac.  Combined with a testing system that made these
changes easy to verify, I think Boost could be very nimble indeed, and
it would be fairly easy to give other people the rights to press that
"merge the changes" button.

> 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....

Hey, sure, why not?  Please feel free to "hit" my libraries ;-)

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