Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-01-01 19:50:49
On 1/1/2011 9:12 AM, Dean Michael Berris wrote:
> On Sat, Jan 1, 2011 at 9:50 PM, Edward Diener<eldiener_at_[hidden]> wrote:
>> On 1/1/2011 4:20 AM, Dean Michael Berris wrote:
>>> 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.
> [snip example]
>>> 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.
>> You can not fail to understand that your idea of collaborative development
>> of your own library is not everybody's way of working. Do not try to force
>> that idea on everybody else.
> Right, so what is the other idea of collaborative development?
> Notice that in the example process I posted, there was the chance for
> me to actually say "no, I don't like this patch". Also, under the same
> example process you can also do the "status quo" process, just don't
> announce your library for inclusion for Boost until you feel it's
> ready and don't accept patches once you've done the announcement. That
> example process allows for the status quo process *and* a more
> collaborative process to happen.
> 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.
> Note that the goal is to lower the barrier to entry, in which the
> current process introduces a lot of (barriers).
> I'm not about to impose anything on anybody -- I was under the
> impression that decisions like these would be a community matter. In
> that case, I don't see why I shouldn't try to ask everybody else to
> change the way they do things because, well, the current process is
> asking me to change the way *I* do things. ;)
You still do not get it. So here it is as plain as I can make it. As a
developer potentially creating for Boost I am interested in creating
libraries myself, documenting and testing them, then offering them to
others to use and comment on. If I feel like the comments will improve
the library, I will improve it. If others do not like the library they
will not use it, or not want it to be part of Boost, or they will create
their own library to do what I have done. I may work on a library with a
very few other people if that suits me, but I feel absolutely no impetus
to work in a collaborative environment with a group of people, each one
of which can contribute to the library in their own way.
Shocking, isn't it. There are still a few souls like me that are not
going to create software as a community effort of people, but
individually as my own design and effort to do something as best as I
can. That does not mean I would not ask or accept help from others or
give help to others if I can. Nor does it mean that I am not
appreciative of the knowledge of others and what they may have to tell
me to improve my efforts. But it does mean that I have almost no
interest in initially creating any piece of software as a community effort.
With all that said my view of community effort is much less harsh than
it may seem. Of course developers should be free if they have the desire
to contribute their effort to a library which already exists, as well as
work on a library initially together if they like. But you should stop
proselytizing for this as the end-all and be-all of all software
development in Boost, as if everything done must be some community of
programmers in some sort of collaborative effort.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk