stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Heimlich, a.k.a. hajma" <tropikha...@gmail.com>
Subject Re: New chair and/or attic
Date Thu, 30 Aug 2012 20:10:47 GMT
On Aug 30, 2012 2:58 PM, C. Bergström <cbergstrom@pathscale.com> wrote:
>
> On 08/30/12 07:29 PM, Liviu Nicoara wrote:
>>
>> On 08/30/12 06:48, "C. Bergström" wrote:
>>>
>>> I'm sincerely sorry to ask this and I have my own answers, but why
continue STDCXX when such negativity from Apache is apparent..
>>
>>
>> AFAICT, the Apache Foundation has been a good host for STDCXX during
these years. They have provided a framework for STDCXX to function in as
well as an infrastructure for its daily activities. All in accordance to
their principles about what constitutes a healthy software project.
>
> I disagree that the recent actions have fostered positive growth in the
project.
> 1) They fired the previous PMC - who was by far the most invested and
dedicated person to the project.  I don't care if he missed some reports or
had a few flippant comments - I think it was pretty stupid (I mean he's
part of the C++ standard committee)
> 2) Posting the project is dead on a public list certainly doesn't help
grow a community

well, it's half year since revival of the project was announced and has
there been any progress/improvements? The state of this is a koma at best.

>
> Hosting and mailing lists can be put almost anywhere and very a menial
thing.  I see discussions like this and bureaucratic non-sense as a dire
roadblock to success.
>
>>
>>>
>>> or
>>> Why not move to libc++? (Yes I realize the amount of effort involved
here)
>>
>>
>> It can't be explained.
>
> Sure it can, but it's biased to perspective and needs.  For example if
libc++ doesn't support Win platforms, or you must maintain STL
compatibility or if you want to have support for C++11 sooner.
>
> I'll contribute time, resources and engineering help if the project moves
away from Apache, but not otherwise.
>
> ./C
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message