Re: [boost] Respecting a projects toolchain decisions

Subject: Re: [boost] Respecting a projects toolchain decisions
From: John Maddock (boost.regex_at_[hidden])
Date: 2010-12-28 04:33:42

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

I only ever look at those issues that are relevent to me, curently not quite 
down to single figures, but close ;-)  and that covers all of config, regex, 
math, type_traits and tr1...

It's also not uncommon for issues to either effect multiple libraries, or to 
need to be reassigned from one library to another, the current system makes 
that trivial - albeit I do wish that Trac had an easier way to get from 
folks real names to their SVN login name (we should probably have insisted 
folks use their real name for this).

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

I'm not sure I follow, I do process issues as they come in, and there is one 
place for regex discussions - right here with [regex] in the title - or on 
any Trac ticket assigned to me.

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

OK you win on that one ;-)

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

Whose doing the reviewing?  IMO it's back to that "one guy" again - OK there 
may actually be more than one person who can do that (as there may be now) - 
but there's still that bottleneck there IMO.

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

IMO there's nothing stopping folks now from getting involved like that, and 
there are a few very welcome folks around here who have their fingers in 
multiple pies and can help out with any of them.  But IMO the central issue 
is getting the volunteers in the first place.

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

The reason it doesn't last all year, is simply not getting enough volunteers 
to run things IMO.

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

I still don't see how changing toolsets helps this - right now you can SVN 
copy a single library into the sandbox *or any other SVN repo of your 
choice* - it took me about 2 minutes flat to do this for a section of 
Boost.Math that I wanted to work on this month - and then away you go, edit 
away to your hearts content, and submit the final result when you're ready. 
I accept that GIT may be a lot easier *for folks that already use it*, just 
as SVN is easier for those of us old timers that have been using that for a 
while.  Of course I didn't see the need to change from CVS to SVN either, so 
you can see where I'm coming from.... :-0

John.