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