Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

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 11:42:21

On Sun, Jan 2, 2011 at 12:20 AM, Dave Abrahams <dave_at_[hidden]> wrote:
>
> On Jan 1, 2011, at 5:12 AM, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
>
>> But what's happening at the moment is that people who *like* the
>> collaborative process *aren't* supported explicitly by the current
>> Boost process. This means what's happening is, the current Boost
>> process is imposing upon me the way to develop a library that I want
>> to develop and am already developing.
>
> I don't see how boost fails to support collaboration. Anyone is free to use Git (or whatever) and whatever community resources they want. Â Nearly everything I've done within boost has been a collaboration.
>

Yes, true, but the context of what I was saying is in the case where a
library being developed for eventual inclusion into Boost is met with
the barrier which is the sandbox, and the review process that happens
only later on in the library's development. Of course a library can be
developed outside of Boost outside of the Boost process first, then
just jump into the process when the library is deemed "ready" for
review -- this is basically what I'm going through with cpp-netlib as
well.

Now though, the point I was trying to address is that the current
process for getting a library into Boost seems to start at the "the
library is ready now" instead of the "here's a good idea, let's work
on it" stage. With a continuous review until it gets "baked right" and
made part of the main distribution that's explicitly supported by the
current process -- i.e., support multiple concurrent libraries under
construction by multiple teams -- and with the reviews being as short
as they are and with timing constraints, the whole point of the peer
review (which is supposed to be the scalable part) becomes the
bottleneck.

Of course the current process forces me to think in a way that makes
the library development/design an individual process, rather than an
open collaborative process. Here's where the implicit and explicit
nature of the process comes in and I think needs to be addressed.

I hope that makes more sense at least. ;)

-- 
Dean Michael Berris
about.me/deanberris