Boost logo

Boost :

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-01 04:20:57

Prelude: The world needs ubiquitous Internet service on the cheap,
because there are parts of the world where the Internet isn't as
accessible. Or... I should really stop engaging in discussions around
holiday times so that I don't miss out on the conversation. ;) That
said, please see in-lined below.

On Wed, Dec 29, 2010 at 2:41 PM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 12/28/2010 9:56 PM, Dean Michael Berris wrote:
>> Actually, I'd +2 if you said a review should be open until the library
>> gets into the main distribution. And even after that, reviewing the
>> quality of the library should be on-going and shouldn't stop at the
>> point of inclusion into Boost. ;)
> If a review, as it sometimes happens, determines that a library does not
> qualify for Boost but if some things were improved it might, I would agree
> with you that a review could be ongoing if the developer of the library is
> committed to maklng changes that would improve it. But I do not see the
> advantage of keeping reviews open until the library is accepted, especially
> with libraries deemed not of a high enough quality for Boost. OTOH nothing
> keeps a developer from making changes in his library and re-submitting it
> for inclusion into Boost again.

Well, there's the rub.

Take what I said in the context of collaborative development instead
of the current way of getting libraries into Boost. My issue with the
status quo is that the barrier to entry for a library (and thus a
contributor) is really high especially because of this practice of not
letting others pitch into the work that goes into writing a library.

As a case in point, I started the implementation of a bloom filter --
it's in the sandbox now, is functional, and some people have already
contributed to the discussion on the development of the library. Back
then there were people saying something about changing the
implementation to do this, or the interface to be like that, etc. -- I
pretty much dropped the development of that library mostly because I
found that the suggestions would have been better in the form of
patches. It is way easier to tell someone "you should do it another
way" instead of actually showing what should be done with code -- and
at the time I was interested in finishing the implementation, there
were too many people saying "do this", or "do that" instead of sending
me patches.

Now what would have been a better process IMO would be something like
the following:

1. Someone (in this case, I) show the community that "hey, I have this
idea for a library that would be cool to include in Boost" -- this
means it's in Github and people can actually get it
2. Those that would have wanted to contribute, would, instead of just
expressing interest, would actually fork the repo and then implement
their contributions in their own repositories, either submit their
changes to me and we can all be co-authors of the library, or just gut
it and tell everyone that here's a better way of doing it, based on
what I've already done (or not).
3. In the process of the library being developed, a review can be
posted by anyone at any given time which would count as a personal
vote for/against the inclusion of the library.
4. Once there are enough "yes" votes, the library can then be
scheduled for inclusion by the release managers -- this means, release
managers would typically either pull, or use something like a git
submodule to manage the libraries to be packaged up.

On-going development of the library can follow that model and the
"review" becomes more a regular part of daily things that happen on
the developer's mailing list. The "management" of the review could be
as simple as setting up a Wordpress Poll or something similar to get
an actual "vote" from the members of the community -- not in an
anonymous manner of course.

This process is nothing like the status quo, and is actually a more
encouraging model that allows people to get involved with minimal
effort required.

> As far as determining the quality of a library on an ongoing basis, anybody
> can currently suggest changes and new features. But I do not believe the
> developer should have to meet those new specs. OTOH I see nothing wrong with
> someone forking the library on his own and producing a second, very similar
> implementation with features he may deem necessary added, updated, or
> changed, and submitting that to Boost. This has already been done in some
> cases, such as signals and signals2, so why should not someone feel that it
> can be done elsewhere with another library.

Sure, but that doesn't make the process collaborative -- which is
actually my main "beef" with the current way things are going. And,
even if someone were to re-write a signals implementation, there's no
need to actually fork it as a separate project as it could very well
just be an evolution of the implementation and just get the
contribution in as part of the normal process. Then, the release
managers just make a determination of whether to actually get a
certain version of the signals implementation from one repo, or get
another from another repo.

I hope this makes sense. :)

PS. If you think about how the stock market indexes work, there's only
a handful of people who choose which listed stock gets to be part of
an index. The S&P 500 is managed by Standard & Poor who rate stocks
according to their performance, suitability, capitalization, etc. and
just list which of these stocks are part of the index. Boost can
follow this model and have release managers -- in behalf of a larger
community -- actually picking libraries which become part of the main
distribution, and libraries that want to be listed follow a process
similar to what the SEC requires companies that want to list on the
NYSE or NASDAQ (of course with less red tape and bureaucracy ;)).
That's the crux of the model I've wanted to convey, but apparently I
needed to sleep on it a little more to get that analogy out. :D

Dean Michael Berris

Boost list run by bdawes at, gregod at, cpdaniel at, john at