Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2017-07-21 14:04:21
Den 21-07-2017 kl. 13:41 skrev Niall Douglas via Boost:
>> The SC can go ahead and implement everything themselves while all the
>> people that did all the real work leave. What a colossal example of
>> arrogance and overstepping. I agree with Vladimir Prus except that I
>> wouldn't vote to reelect any of them--including those that have
>> contributed to Boost. And, no, Niall, having done some good does not
>> make someone above reproach.
> I have seen some enormously ignorant, petty and sanctimonious guff
> spoken here during this thread, sufficiently so that it makes Reddit
> look a positive bastion of enlightenment and positivity. It paints the
> Boost developer community in a sorry light, very sad. But I felt it was
> important for the SC to handle its own PR, so I have said nothing and
> will continue to do so.
Right. Where is the SC?
> So stop dumping hate on the non-technical admin side of Boost and C++.
> If you have a problem with them, it's the same as library development:
> if you'd like the non-technical admin to be done differently,
> **volunteer** and join the small army who do the non-technical admin.
> Otherwise stop whining when they take decisions that you don't like.
The problem might be that if you don't involve the developers,
they get very offended, and for good reasons.
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk