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: Joel de Guzman (joel_at_[hidden])
Date: 2011-01-01 20:38:52

On 1/1/2011 5:20 PM, Dean Michael Berris wrote:
> On Wed, Dec 29, 2010 at 2:41 PM, Edward Diener<eldiener_at_[hidden]>  wrote:
 >
>> 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.

Dean, you have very good points. We all want to have better processes in
place and we all agree that there are various aspects of boost process
that can be improved.

However, in my opinion, there's nothing wrong with the collaborative
environment in Boost. I've been collaborating with other Boost-izens
for almost a decade now and that extends long before I got my first
library into Boost. In my experience, collaboration started as soon as
I introduced my library into Boost in the all-too-familiar "is anyone
interested" fashion. Pre-boost collaboration happened at SourceForge
for Spirit. Today, that may very well be github. I fail to see any problem
with that.

Git may be the next greatest tool out there. N-years down the line, it may
be Wow-xxx or Geez-yyy or whatever, which will give us M more features.
Then, one very bright individual will advocate the latest "greatest" tool
proclaiming that he can't live without the features of Geez-yyy and
that the current tools are broken and that if you begin to use Geez-yyy,
you don't want to go back.

Do we see a pattern emerging? I think it's an effect of the gadget
generation. As for us, Spirit folks, we are quite happy with whatever
tools Boost provides for us. We will continue to collaborate and innovate
regardless of the tools.

Remember: A bad craftsman always blames his tools.

That said, I want to end this with a constructive note. I do think that
you have very valid points and suggestions. My suggestion: focus on
improving the process without focusing too much on the tools. As much
as possible, take advantage of whatever tools are set in place.

***Prefer evolution instead of revolution.***

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net