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-27 10:57:54

On Mon, Dec 27, 2010 at 11:39 PM, Nelson, Erik - 2
<erik.l.nelson_at_[hidden]> wrote:
> Dean Michael Berris wrote on Monday, December 27, 2010
>
> On Mon, Dec 27, 2010 at 1:27 PM, Vladimir Prus
> <vladimir_at_[hidden]> wrote:
>>> Would you please specify a concrete example where innovation in a
>>> library that you personally is contributing to is slowed down by
>>> centralized version control?
>>>
>
>>Boost.Pool is one, and the other was Boost.Iterators.
>>With Boost.Pool, there's no maintainer around (that I know)
>>who's checking patches submitted to it and making sure
>>the changes make it into the releases.
>>With Boost.Iterators, it took a while to get a patch for an
>>additional iterator implementation to get into trunk -- and
>>I'm not even sure if my patch has made it into the release yet.
>
> It's not clear to me that these problems have anything to do with
> Subversion... regardless of which vcs is used, *someone* is going to be
> the designated maintainer/owner of the library, and if you can't get
> them to include your patches, your patches won't be in the Boost
> release, right?
>

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.

> In that case you'd need to do the same thing you would do under the
> current system... get yourself named maintainer/owner and then do it
> yourself.
>

Well, it's really not that easy -- becoming maintainer of something is
a lot more baggage than just that guy who made changes and had his
changes pulled into the main release. I should know as a maintainer of
cpp-netlib at the moment. ;)

> Am I missing something there?
>

Maybe just the background information that has been expressed in a
different thread, which I kind of assumed would be read along the same
line as this one -- which may be my mistake. :D

> It seems to me that there's no shortage of innovation going on in
> Boost... I've seen many fine libraries released over the years. Â My
> observation is that there's some shortage of people who want to do the
> laborious work... review manager, release manager, BoostCon organizer,
> etc. Â My hat's off to the folks that do the heavy lifting there, and it
> seems reasonable that they should have a larger voice on how that
> process works.
>

Sure, if you think having 20+ libraries in the review queue and lots
of patches waiting around for years in Trac and then seeing some of
your efforts being either ignored or forgotten to be a good enough
pace of innovation... then I can say yeah, there's good innovation
going on. ;)

But seriously, it's not about the lack of innovation, it's just that
the pace and means apparently does not scale. The suggestions being
raised (by me) are meant to reduce the amount of work and lower the
barrier to entry for potential contributors/maintainers of Boost
libraries both present and future.

-- 
Dean Michael Berris
about.me/deanberris