Subject: Re: [boost] RFC.. Steering Committee Bylaws Proposal
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-10-18 15:58:01
On 10/18/17 8:10 AM, Rene Rivera via Boost wrote:
> Nah.. Programmers have a long history of accepting edicts about the tools
> and methods that others proclaim. And I doubt this will be any different
> from that history.
> Let's keep muddling on ;-)
> Right.. Lets accept what is given without any say on it.
>> and Carry On Coding :-)
> Sure.. We'll rowing to the drum beat.
I fear that you've fallen into the same trap that the steering committee
has - that what they say makes a lot of difference. They can do a lot
of things: spend some money, make proclamations, pass a code of conduct,
stuff like that - but nothing really of substance. If you want proof
just look at the last attempt to impose CMake. What they can do is to
try to recognize, and build concensus. That is, buy the time the issue
has ripened to the point that there is a consensus, they can climb on
board to give the impression that they actually did something. Witness
the successful transition to git from svn - which was much simpler by
the way. So they can make a difference at the margin. But the rest is
just a facade. Of course this is not a phenomenon unique to boost - its
the general way of doing things in civilized society. Hence we see
boards of directors filled with prestigious names who spend only a
couple of days a year "working" to give give "guidance and direction" to
the organization. (The boost steering committee is an exception of
course) Don't think of this as a negative thing - imagine what the world
would be like if these people actually did run things. Actually you
don't have to imagine, consider the soviet politburo for obvious example.
I've been a regular complainer about a number of aspects of boost build
over the years, but I have huge respect for the developers of the
current boost build setup. They have been reliable maintainers of the
system and it's something we have been able to depend upon. But it has
problematic aspects which have never been addressed. So here we are.
Anyway, there are good reasons for Boost to support those who want/need
to use CMake. I DO think there is a consensus about this. The problem
is that it's not clear what this would really mean and require. CMake
has facets for building IDE, a GUI vs Command line interface, Building
libraries, Setting up and running tests, Posting tests results to a
dashboard, and deployment of packages. Understanding these different
facets currently requires one to spend a lot of time googling CMake
explanations - none of which is particularly clear and comprehensive.
There are open questions regarding how this would work in the context of
Boost. E.G what this means for users vs developers, what facilities from
CMake we might want to use and how it would provide facilities which we
currently depend upon. It's stunning to me that in spite of a widely
held view that that boost should support CMake, no one has posted a real
proposal about what parts we should use, how we should use them to
support development, maintenance, testing, deployment of the federation
of libraries which currently constitute boost. Until such a proposal is
presented, no progress can be made.