Re: [boost] Respecting a projects toolchain decisions

Subject: Re: [boost] Respecting a projects toolchain decisions
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-28 06:20:02

On Tue, Dec 28, 2010 at 2:33 PM, Jim Bell <Jim_at_[hidden]> 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