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 00:12:24

On Tue, Dec 28, 2010 at 2:14 AM, John Maddock <boost.regex_at_[hidden]> wrote:
>>
>> 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.
>

Right. There's a different way of looking at it too:

"At least we have a centralized place to put garbage in and let it
rot, what we really need is more folks to segregate the trash and
manage one big pile"

To me at least, that centralized place to gather patches/bug
reports/feature requests isn't actually a good thing. Let me state a
few reasons why I think this:

1. The signal/noise ratio can be hard to keep down especially if you
have a lot of ground to cover. Consider how you (or any other
maintainer for example) would want to manage a part of the 1000
tickets that are all in the same pile. Sure you can query it many
different ways, but wouldn't it be way easier to just look at 100
issues just for Boost.Regex than it is to spend some time looking at
1000 issues that might be relevant to Boost.Regex?

2. It's harder to divide and conquer if you start from the top-down.
Let me qualify that a little: if you start with one big-ass pile of
dung, the stink is much harder to overcome than if you processed the
input as it comes in and segregate bottom-up (no pun intended). If you
had one place where issues for Boost.Regex gets tracked, where
discussion around Boost.Regex gets documented, where design decisions
are hashed out, and where documentation is ultimately developed, then
your progress with dealing with Boost.Regex shouldn't hamper the
progress and development of other libraries not dependent on
Boost.Regex. This means issues for Boost.Proto don't get piled into
the same pile of issues where Boost.Regex issues will be piled on.
Processing the issues as they come in would be way easier to manage
than if you started with one pile containing both issues.

3. I'm not sure how the "single point of failure" comes into play, but
centralized anything means that one thing goes down, then everything
fails. I don't think I need to stress that point any more than I have
to. ;)

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

Unfortunately, insisting on "that one guy" being there and doing what
you describe as essentially maintenance, is actually part of the
reason why the development model doesn't scale IMHO.

Being able to trust people and empowering people to actually be able
to just muck around with things and then asking for changes -- that
still need to be reviewed anyway -- to get baked in and shepherded by
trusted people (note, not just "that one guy") lowers the barrier to
entry for contributors. It's actually a better problem to have if you
have 10x more contributors than it is to have 10x more issues. Because
sending patches around is brittle and a nightmare to manage, using
tools that make it easier should be a welcome development I imagine.

That said, consider the case where you have 5 trusted people who you
know already know the Boost.Regex internals either as much as you do
or better, then have 10 people who implement new features and make
changes to the implementation -- would you rather be the one to deal
with the changes of these 10 people or would you welcome the word of
any of the 5 trusted people to apply changes that any of the 10 people
make on your behalf? Essentially in the current parlance, these 5
trusted people would normally be called "co-maintainers", and the 10
people would be called "potential contributors"; in case any of the 10
potential contributors have their changes pulled in, then they become
"contributors".

Then apply this above logic to every Boost library that's actively
maintained (and maybe not so actively maintained) and then you have a
wider contribution base -- maybe some people would call it a more
scalable model, but I don't want to jump the gun on that 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. Â In fact
> if folks think that might be a good idea, I might be moved to try and
> organize something....
>

Sure, that's a thought, but that's thinking with a band-aid short-term
solution. The bug sprints are a good idea, but I don't get why a bug
sprint can't last 1 whole year and be an on-going effort. Having bug
sprints and hit squads (ninja clans, strike teams, etc.) are
short-term non-sustainable solutions to the issue of open source
maintenance.

I'd for one as a potential contributor would like to be encouraged to
dive into the code, get some changes submitted, and see that there are
people who actually care. With the current process and system in
place, I don't feel like it's a conducive environment for potential
contributors only just because of the barriers to entry.

Although I agree that it weeds out the people who aren't serious about
contributing, I don't see it encouraging more people to be
contributors either.

> Just my 2c, John.

Definitely worth much more IMO. :)

Thanks John.

-- 
Dean Michael Berris
about.me/deanberris