Re: [boost] RFC.. Steering Committee Bylaws Proposal

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.

Robert Ramey