The problem might be that if you don't involve the developers, they get very offended, and for good reasons.
As no less than two members of the SC have already said here in this thread, boost-dev was consulted and in depth, with at least three boost-dev members proposing technical cmake solution prototypes for the SC to consider. The same old arguments were made, nothing new over previous discussions of the merits or non-merits of cmake vs boost.build were advanced. The SC therefore decided that this decision was making no progress due to stalemate, and enforced a decision. You probably wanted some big banner in the Subject line like "IF YOU DON'T SPEAK NOW THEN CMAKE IS HAPPENING". But the way that the SC was originally set up doesn't allow that to happen. Nobody from the SC can claim that the SC will take some action until they *have* taken some action, and they can't take an action until a *formal* written proposal has been laid before them to vote upon. Formal written proposals land before the SC to vote on all the time. Some are rejected, some approved. I've written a few myself, but not recently as I am winding down my involvement with Boost.
If you had taken any time to be familiar with what is discussed in the non-technical admin community, then this decision about cmake above was obviously coming over this past year. I was part of multiple off list discussions, and that was a small subset of the total ongoing. Indeed, it's why I've been so sweetness and nice here on boost-dev in the past year, I was finally seeing some movement on choosing a direction for Boost after many years of trying to no avail. So no longer any need to be nasty here anymore. And for the record, more controversial breaking change is coming. So don't be surprised when it lands.
Huh? More announcements of decisions behind closed doors without list discussions?
All stakeholders involved in the cmake decision were consulted in depth and many weeks in advance. There was nothing closed door about it. Search the boost-dev archives, it's there.
Look, everybody here would like Boost to be easier to consume for end users. But that's a goal that needs a plan and means and feasibility studies. Secondary, should we abandon boost.build internally? That's a different thing entirely.
I hope the SC realize how damaging their actions are.
You all should read the announcement again. The only decision enforced was that cmake is going to happen. Nothing was said about form, design, process, timetable, or anything else. Nothing was said about removing Boost.Build either. Quite frankly the reaction here was way overblown to what had happened. But then if you don't maintain a steady beat of breaking change, people way overreact when it comes. And we haven't had a breaking change here since the git migration five years ago. And that was *awful*. So far, this is going better. Long may it continue. Nothing in any of this reply has not already been previously said on this thread by SC members. I am, quite literally, repeating what they already have said here, despite that I am not a member of the SC. I just pay attention to what people write on boost-dev. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/