On Sun, Jan 2, 2011 at 9:38 AM, Joel de Guzman <joel@boost-consulting.com> 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