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-02 09:48:53

On Sun, Jan 2, 2011 at 9:38 AM, Joel de Guzman
<joel_at_[hidden]> wrote:
> On 1/1/2011 5:20 PM, Dean Michael Berris wrote:
>>
>> 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.
>

Thanks. :)

> 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.
>

True, there are a lot of people already collaborating now and the
environment is actually good -- for people already within the process,
i.e. have subversion access to the sandbox, are active in the mailing
list, are comfortable with creating patches and submitting them
through Trac.

Also, just for the record, I have no issue with the way collaboration
is happening now. What I do have an issue with is the realization that
the current process doesn't scale and the barrier to entry is pretty
high even to those most determined to contribute -- and the tools we
use currently which don't allow for a scalable means of accommodating
more contributors and more effective collaboration.

The idea is to tweak the current process, so that the collaboration
can happen in a scalable fashion as compared to what's happening now.
The prerequisite to that would be making the contribution process
easier -- either to the libraries under construction, or those that
are already in the distribution.

> 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.
>

I for one would like to think that I'm not part of that gadget
generation you refer to. ;-)

Kidding aside, I see that the Spirit development effort has an
effective means of releasing versions of Spirit that are "pulled in"
(or in this case, merged into) the Boost Release. I also see that
Spirit has a process on its own and a community on its own of users
and developers. Same goes for Asio, which AFAIK has a mailing list and
a different development timeline.

This is really the point I was trying to make: to encourage people to
do the same, but this time in a slightly different (and arguably more
scalable) paradigm. Instead of there being just one Boost library
project where the chaos of innovating libraries and getting the
consensus on which libraries to include in the distribution happens in
a single place (centralized), that there may very well be multiple
library projects that have their own development pace and a means of
pulling a distribution together in a non-obtrusive and "seamless"
manner (decentralized).

> Remember: A bad craftsman always blames his tools.
>

Yes, and a good craftsman knows when the tools he uses aren't enough
for the project at hand. ;-)

> 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.***
>

Thanks, I'll try to think of a way to make the decentralized
development of Boost libraries happen with tools that work in a
different paradigm.

At the moment, the best model that I know of a scalable open source
project in terms of development, evolution, and lowered barrier to
entry for contributors is the one that the Linux kernel and the Linux
distribution projects follow. In these settings, the decentralized
system is the one that works and where collaboration and active
involvement is encouraged (and nurtured).

Thanks again Joel. :)

-- 
Dean Michael Berris
about.me/deanberris