On Tue, Dec 28, 2010 at 2:33 PM, Jim Bell <Jim@jc-bell.com> wrote:
On 1:59 PM, John Maddock wrote:
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>
+1 for 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.
I'd say "ticket handlers" would be another word of "trusted developers". In the system I was thinking of using Git+GPG having someone sign the changes/patches would be a good way of marking that they trust a patch and are willing to accept it into their own repository. By signing the changes a contributor/developer puts his reputation on the line with every patch he accepts into his repository -- and the same goes until the changes get to the top. It's pretty hard for me to visualize this bottom-up approach to getting changes up the line, maybe I'll try a diagram at some point if it doesn't make sense yet.
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.
This is, in other projects, called a developer community -- and they don't need a name like "hit squad" and "guild". ;)
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?
I have a reservation on this idea which I've already expressed in a separate reply on the same thread. That said, if it's really what people in Boost would want to do, then I guess I'll just go along with the flow -- and complain loudly as I can along the way. ;) -- Dean Michael Berris about.me/deanberris