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: Edward Diener (eldiener_at_[hidden])
Date: 2011-01-01 08:50:07

On 1/1/2011 4:20 AM, Dean Michael Berris wrote:
> 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.

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.