You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by "William A. Rowe Jr." <wr...@rowe-clan.net> on 2012/02/02 18:03:58 UTC
[VOTE] Retirement of stdcxx to the 'Attic'?
Fans and contributors,
it appears that the stdcxx project is entirely dormant. The ASF has
launched a new 'Attic' project over the past two years, to neatly
retire dormant works until and unless a community comes along who
wishes to revive the effort.
As a simple formality your votes please;
[ ] +1 - stdcxx committee should be retired, with code sent to the Attic
[ ] -1 - No, stdcxx should not fold, I am still contributing, and
[would serve|am serving] on its project management committee
The results of this vote will be taken up by the ASF Board of Directors
at their 15 Feb meeting.
RE: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Travis Vitek <Tr...@roguewave.com>.
While often have little or no time for extracurricular activities, I'm willing to start participating on a limited basis.
So -1.
Travis
-----Original Message-----
From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
Sent: Thursday, February 02, 2012 9:04 AM
To: dev@stdcxx.apache.org
Subject: [VOTE] Retirement of stdcxx to the 'Attic'?
Fans and contributors,
it appears that the stdcxx project is entirely dormant. The ASF has
launched a new 'Attic' project over the past two years, to neatly
retire dormant works until and unless a community comes along who
wishes to revive the effort.
As a simple formality your votes please;
[ ] +1 - stdcxx committee should be retired, with code sent to the Attic
[X] -1 - No, stdcxx should not fold, I am still contributing, and
[would serve|am serving] on its project management committee
The results of this vote will be taken up by the ASF Board of Directors
at their 15 Feb meeting.
Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Posted by Martin Sebor <ms...@gmail.com>.
Stefan,
Smaller, independent patches are better for a few reasons: they
are easier to review, and easier to back out if they cause trouble.
In addition, they'll give you the opportunity to get comfortable
with the process. After you submit a few good patches over a period
of time we'll also be able to get you commit privileges. Since none
of the rest of us has the time to contribute patches of our own,
adding a committer who does is essential to keep the project alive.
Martin
PS For tracking purposes, it would be ideal to start by opening
a new Jira issue for each patch you plan to submit.
On 02/04/2012 08:15 AM, Stefan Teleman wrote:
> OK I will start submitting patches at stdcxx. Breaking them up into
> smaller chunks will increase the number of patches though. :-) Stay
> tuned.
>
> I don't intend to push changes to the build system - we use gmake to
> build stdcxx at Oracle.
>
> --Stefan
>
> ----
>
> On Fri, Feb 3, 2012 at 16:48, Andrew Black<An...@roguewave.com> wrote:
>> Like Farid, I too am willing to help process patches for review and
>> submission. Once a track record has been established, someone on the PMC
>> would likely raise a motion to designate you as a committer, as defined at
>> http://stdcxx.apache.org/#committers . This would allow you to make changes
>> directly to subversion without assistance. Do note that in order to be
>> designated as such, you will need to have a Contributor License Agreement (
>> http://www.apache.org/licenses/icla.txt ) on file with the Apache
>> foundation. If you are being paid to perform this work, the company you work
>> for will likely need to have a Corporate Contributor License Agreement (
>> http://www.apache.org/licenses/cla-corporate.txt ) on file.
>>
>> If we are trying to revitalize this project, there are a few things I
>> personally would/would not like to see in the patches:
>> * I would not like to see major changes to the build infrastructure at this
>> time. One of the goals of this project has been portability, and this
>> includes the build infrastructure. My understanding is that gmake is
>> considered to be more portable than some of the alternatives (cmake, ant).
>> * I would like to see tests added to verify any library changes. Ideally the
>> new tests will pass on most platforms, though we don't currently have an
>> automated test mechanism in place. If any existing tests are incorrect,
>> commentary for the change about why they are broken would be appreciated.
>> * Changes destined for the 4.2.x branch should have forwards and backwards
>> binary compatibility.
>> * Changes destined for the 4.3.x branch should have backwards source
>> compatibility.
>>
>> --Andrew Black
>>
>>
>> On 02/03/2012 03:04 PM, Farid Zaripov wrote:
>>>
>>> On 03.02.2012 1:52, Stefan Teleman wrote:
>>>>
>>>> 2. Someone with stdcxx commit privileges should be part of this
>>>> reunification (for obvious reasons). It is very discouraging to submit
>>>> patches knowing full well and ahead of time that they will never make
>>>> it anywhere. Perhaps the process of submitting patches could be
>>>> somewhat less of a "process". Just my 0.02. --Stefan
>>>
>>>
>>> Stefan, if you split the all your patches to a set of small finalized
>>> changes and submit them through a set of corresponding issues in JIRA, I
>>> promise I will process them all one by one.
>>> At the moment I don't see any issues, reported by you. Sorry, but
>>> process is a process.
>>>
>>> Farid.
>>>
>>
>
>
>
Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Posted by Stefan Teleman <st...@gmail.com>.
OK I will start submitting patches at stdcxx. Breaking them up into
smaller chunks will increase the number of patches though. :-) Stay
tuned.
I don't intend to push changes to the build system - we use gmake to
build stdcxx at Oracle.
--Stefan
----
On Fri, Feb 3, 2012 at 16:48, Andrew Black <An...@roguewave.com> wrote:
> Like Farid, I too am willing to help process patches for review and
> submission. Once a track record has been established, someone on the PMC
> would likely raise a motion to designate you as a committer, as defined at
> http://stdcxx.apache.org/#committers . This would allow you to make changes
> directly to subversion without assistance. Do note that in order to be
> designated as such, you will need to have a Contributor License Agreement (
> http://www.apache.org/licenses/icla.txt ) on file with the Apache
> foundation. If you are being paid to perform this work, the company you work
> for will likely need to have a Corporate Contributor License Agreement (
> http://www.apache.org/licenses/cla-corporate.txt ) on file.
>
> If we are trying to revitalize this project, there are a few things I
> personally would/would not like to see in the patches:
> * I would not like to see major changes to the build infrastructure at this
> time. One of the goals of this project has been portability, and this
> includes the build infrastructure. My understanding is that gmake is
> considered to be more portable than some of the alternatives (cmake, ant).
> * I would like to see tests added to verify any library changes. Ideally the
> new tests will pass on most platforms, though we don't currently have an
> automated test mechanism in place. If any existing tests are incorrect,
> commentary for the change about why they are broken would be appreciated.
> * Changes destined for the 4.2.x branch should have forwards and backwards
> binary compatibility.
> * Changes destined for the 4.3.x branch should have backwards source
> compatibility.
>
> --Andrew Black
>
>
> On 02/03/2012 03:04 PM, Farid Zaripov wrote:
>>
>> On 03.02.2012 1:52, Stefan Teleman wrote:
>>>
>>> 2. Someone with stdcxx commit privileges should be part of this
>>> reunification (for obvious reasons). It is very discouraging to submit
>>> patches knowing full well and ahead of time that they will never make
>>> it anywhere. Perhaps the process of submitting patches could be
>>> somewhat less of a "process". Just my 0.02. --Stefan
>>
>>
>> Stefan, if you split the all your patches to a set of small finalized
>> changes and submit them through a set of corresponding issues in JIRA, I
>> promise I will process them all one by one.
>> At the moment I don't see any issues, reported by you. Sorry, but
>> process is a process.
>>
>> Farid.
>>
>
--
Stefan Teleman
KDE e.V.
stefan.teleman@gmail.com
RE: [disscuss] Retirement of stdcxx to the 'Attic'?
Posted by Wojciech Meyer <Wo...@arm.com>.
> * I would not like to see major changes to the build infrastructure at
> this time. One of the goals of this project has been portability, and
> this includes the build infrastructure. My understanding is that gmake
> is considered to be more portable than some of the alternatives (cmake,
> ant).
I might disagree with that, since gmake on windows not only needs
gmake.exe on path but also a several Cygwin tools. Also MSVC port needs
separate nmake instructions. On other hand Cmake has - not nice indeed -
a specialized language separated from the platform to regenerate needed
build boilerplate.
Just mine 2 cents,
Wojciech
________________________________________
From: Andrew Black [Andrew.Black@roguewave.com]
Sent: Friday, February 03, 2012 9:48 PM
To: dev@stdcxx.apache.org
Subject: Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Like Farid, I too am willing to help process patches for review and
submission. Once a track record has been established, someone on the PMC
would likely raise a motion to designate you as a committer, as defined
at http://stdcxx.apache.org/#committers . This would allow you to make
changes directly to subversion without assistance. Do note that in order
to be designated as such, you will need to have a Contributor License
Agreement ( http://www.apache.org/licenses/icla.txt ) on file with the
Apache foundation. If you are being paid to perform this work, the
company you work for will likely need to have a Corporate Contributor
License Agreement ( http://www.apache.org/licenses/cla-corporate.txt )
on file.
If we are trying to revitalize this project, there are a few things I
personally would/would not like to see in the patches:
* I would not like to see major changes to the build infrastructure at
this time. One of the goals of this project has been portability, and
this includes the build infrastructure. My understanding is that gmake
is considered to be more portable than some of the alternatives (cmake,
ant).
* I would like to see tests added to verify any library changes. Ideally
the new tests will pass on most platforms, though we don't currently
have an automated test mechanism in place. If any existing tests are
incorrect, commentary for the change about why they are broken would be
appreciated.
* Changes destined for the 4.2.x branch should have forwards and
backwards binary compatibility.
* Changes destined for the 4.3.x branch should have backwards source
compatibility.
--Andrew Black
On 02/03/2012 03:04 PM, Farid Zaripov wrote:
> On 03.02.2012 1:52, Stefan Teleman wrote:
>> 2. Someone with stdcxx commit privileges should be part of this
>> reunification (for obvious reasons). It is very discouraging to submit
>> patches knowing full well and ahead of time that they will never make
>> it anywhere. Perhaps the process of submitting patches could be
>> somewhat less of a "process". Just my 0.02. --Stefan
>
> Stefan, if you split the all your patches to a set of small finalized
> changes and submit them through a set of corresponding issues in JIRA, I
> promise I will process them all one by one.
> At the moment I don't see any issues, reported by you. Sorry, but
> process is a process.
>
> Farid.
>
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Posted by Andrew Black <An...@roguewave.com>.
Like Farid, I too am willing to help process patches for review and
submission. Once a track record has been established, someone on the PMC
would likely raise a motion to designate you as a committer, as defined
at http://stdcxx.apache.org/#committers . This would allow you to make
changes directly to subversion without assistance. Do note that in order
to be designated as such, you will need to have a Contributor License
Agreement ( http://www.apache.org/licenses/icla.txt ) on file with the
Apache foundation. If you are being paid to perform this work, the
company you work for will likely need to have a Corporate Contributor
License Agreement ( http://www.apache.org/licenses/cla-corporate.txt )
on file.
If we are trying to revitalize this project, there are a few things I
personally would/would not like to see in the patches:
* I would not like to see major changes to the build infrastructure at
this time. One of the goals of this project has been portability, and
this includes the build infrastructure. My understanding is that gmake
is considered to be more portable than some of the alternatives (cmake,
ant).
* I would like to see tests added to verify any library changes. Ideally
the new tests will pass on most platforms, though we don't currently
have an automated test mechanism in place. If any existing tests are
incorrect, commentary for the change about why they are broken would be
appreciated.
* Changes destined for the 4.2.x branch should have forwards and
backwards binary compatibility.
* Changes destined for the 4.3.x branch should have backwards source
compatibility.
--Andrew Black
On 02/03/2012 03:04 PM, Farid Zaripov wrote:
> On 03.02.2012 1:52, Stefan Teleman wrote:
>> 2. Someone with stdcxx commit privileges should be part of this
>> reunification (for obvious reasons). It is very discouraging to submit
>> patches knowing full well and ahead of time that they will never make
>> it anywhere. Perhaps the process of submitting patches could be
>> somewhat less of a "process". Just my 0.02. --Stefan
>
> Stefan, if you split the all your patches to a set of small finalized
> changes and submit them through a set of corresponding issues in JIRA, I
> promise I will process them all one by one.
> At the moment I don't see any issues, reported by you. Sorry, but
> process is a process.
>
> Farid.
>
Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Posted by Farid Zaripov <fa...@zaripov.kiev.ua>.
On 03.02.2012 1:52, Stefan Teleman wrote:
> 2. Someone with stdcxx commit privileges should be part of this
> reunification (for obvious reasons). It is very discouraging to submit
> patches knowing full well and ahead of time that they will never make
> it anywhere. Perhaps the process of submitting patches could be
> somewhat less of a "process". Just my 0.02. --Stefan
Stefan, if you split the all your patches to a set of small finalized
changes and submit them through a set of corresponding issues in JIRA, I
promise I will process them all one by one.
At the moment I don't see any issues, reported by you. Sorry, but
process is a process.
Farid.
Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Posted by Stefan Teleman <st...@gmail.com>.
On Thu, Feb 2, 2012 at 17:57, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> The much larger issue is that the ASF is designed as a collaboration
> hub where multiple consumers can be represented. It is designed to
> avoid the need for forks except in radical divisions within communities
> where two or more groups want the code to proceed in different directions.
> In order to remain a project, the ASF requires a PMC composed of the
> contributors to the project (committers) which represent active user -
> developers of the project's code, and are willing to both incorporate
> all reasonable changes and draw in new individuals who are frequently
> offering those changes.
>
> As a standards body implementation, we would /hope/ there aren't huge
> fractures in the direction of the code :)
>
> If there are multiple forks at this point, the questions are why, and
> what can be done to bring it all back together into a single community
> where no one company or individual is shouldering the burden of
> entirely maintaining the code on their own.
>
> Feel free to chime in here on these questions.
Speaking for the Solaris/Sun Studio C++ "fork":
To begin with, it's not a fork. Or at least it was never intended to
be a fork (and still isn't). It's simply a very large collection of
patches, based on stdcxx 4.2.1. This was the last "official" stdcxx
release published at the ASF, and that's the release we used as a
starting point in Solaris.
There are three categories of patches:
1. Patches specific to Solaris and Sun Studio. These affect stdcxx's
GNUmakefiles*, sunpro.config and gcc.config. The GNUmakefile* patches
can probably be ignored for a general-purpose relase. The
sunpro.config and gcc.confnig patches are useful for building on
Solaris.
2. Patches pertaining to a specific set of Solaris SPARC
idiosyncracies. You can find more details about these patches here:
https://issues.apache.org/jira/browse/STDCXX-1040
3. Patches for stdcxx issues which were discovered while running the
stdcxx test harness, and for which there was no canonical resolution.
For example:
https://issues.apache.org/jira/browse/STDCXX-839
Turns out that std::numpunct<> and std::moneypunct<> are thread-unsafe
(because of the std::basic_string's copy constructor and shared buffer
implementation).
3. Patches for issues discovered during C++2003 validation testing:
I wrote the patches based on failures or violations discovered while
running the Perennial CPPVS 8.1 (which is what we use internally) and
some other simple, trivial tests on stdcxx with Sun Studio C++.
These are "general-purpose" patches, they address problems independent
of platform or architecture. This is the largest set of patches.
Caveat: some (a few) of these patches break BC with the existing
stdcxx 4.2.1 implementation. This may be a problem at ASF; for Solaris
we had the advantage that stdcxx was new, and we could afford to break
BC (because there was nothing to maintain BC with in the first place).
Why did these patches never make it into stdcxx: because by the time I
started submitting them here, stdcxx was already on its way to
becoming dormant. Or at least very sleepy. A small set of very simple
patches made it into the yet-unreleased 4.2.2, but the big set of
complex patches never made it.
At any rate, you can find the complete set of Studio C++ patches here:
http://kdesolaris-svn.cvsdude.com/trunk/STDCXX/4.2.1/
http://kdesolaris-svn.cvsdude.com/trunk/STDCXX/4.2.1/Solaris/
The README.Solaris file is out-of-date and very obsolete. Please ignore it.
This set of patches generates a stdcxx identical to that available
with Solaris 10 and 11, with two exceptions:
ios_base.failure.90.diff and
stdexcept.91.diff
aren't part of the Solaris canonical stdcxx release. Strictly
technically speaking, std::ios_base::failure should be a class, and
not a typedef (and making it a typedef, as it is in the stdcxx
implementation causes a failure on a very specific and otherwise
obscure CPPVS test case). However, making it a proper class (as it is
declared in 27.4.2.1.1) has a noticeable performance impact) so we
decited to leave it as is.
svn co should work anonymously. If it doesn't please let me know.
"what can be done to bring it all back together into a single community":
1. Don't retire it to the Attic. :-) The Attic pretty much guarantees
that it will never be brought back all together.
2. Someone with stdcxx commit privileges should be part of this
reunification (for obvious reasons). It is very discouraging to submit
patches knowing full well and ahead of time that they will never make
it anywhere. Perhaps the process of submitting patches could be
somewhat less of a "process".
Just my 0.02.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.teleman@gmail.com
Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/2/2012 2:17 PM, Andrew Black wrote:
> While I am not completely familiar with the process, I took a couple minutes to look at
> the website for the Attic project ( http://attic.apache.org/ ), and I thought I'd
> summarize the implications of this move as I understand them.
Good summary.
> * The project is forked. I get the impression that there are at least a couple informal
> forks of the codebase out there, but I have neither the time nor inclination to follow
> these forks and commit the changes back to subversion. The Attic website says they will
> link to any forks which have been created, but I don't know what criteria must be met for
> this to happen.
The much larger issue is that the ASF is designed as a collaboration
hub where multiple consumers can be represented. It is designed to
avoid the need for forks except in radical divisions within communities
where two or more groups want the code to proceed in different directions.
In order to remain a project, the ASF requires a PMC composed of the
contributors to the project (committers) which represent active user -
developers of the project's code, and are willing to both incorporate
all reasonable changes and draw in new individuals who are frequently
offering those changes.
As a standards body implementation, we would /hope/ there aren't huge
fractures in the direction of the code :)
If there are multiple forks at this point, the questions are why, and
what can be done to bring it all back together into a single community
where no one company or individual is shouldering the burden of
entirely maintaining the code on their own.
Feel free to chime in here on these questions.
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Andrew Black <An...@roguewave.com>.
While I am not completely familiar with the process, I took a couple
minutes to look at the website for the Attic project (
http://attic.apache.org/ ), and I thought I'd summarize the implications
of this move as I understand them. A move to the attic means the
following (major) changes to the STDCXX project:
* The STDCXX PMC will be dissolved.
* The following resources will be made read-only:
** The subversion repository ( http://svn.apache.org/repos/asf/stdcxx )
** The JIRA project ( http://issues.apache.org/jira/browse/STDCXX )
** The wiki ( http://wiki.apache.org/stdcxx/ )
* The dev@, commits@ and private@ mailing lists will be closed
Once the project has been moved to the attic, it will only be moved out
if one of the following events happen:
* The community is restarted in the Apache Incubator.
* The PMC is recreated.
* The project is forked. I get the impression that there are at least a
couple informal forks of the codebase out there, but I have neither the
time nor inclination to follow these forks and commit the changes back
to subversion. The Attic website says they will link to any forks which
have been created, but I don't know what criteria must be met for this
to happen.
--Andrew Black
On 02/02/2012 12:03 PM, William A. Rowe Jr. wrote:
> Fans and contributors,
>
> it appears that the stdcxx project is entirely dormant. The ASF has
> launched a new 'Attic' project over the past two years, to neatly
> retire dormant works until and unless a community comes along who
> wishes to revive the effort.
>
> As a simple formality your votes please;
>
> [ ] +1 - stdcxx committee should be retired, with code sent to the Attic
>
> [ ] -1 - No, stdcxx should not fold, I am still contributing, and
> [would serve|am serving] on its project management committee
>
> The results of this vote will be taken up by the ASF Board of Directors
> at their 15 Feb meeting.
RE: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Wojciech Meyer <Wo...@arm.com>.
Hi William,
On 2/5/2012 10:36 AM, Wojciech Meyer wrote:
> > This is partially because stdcxx is still considered to be a derivate
> > implementation of RogueWave in ARM toolchain, so upgrading at some
> > point would have had a smaller impact on our customers than porting
> > the toolchain into another library, apart from that I think this means
> > that we will have yet smaller choice of C++ libraries avaiable - even
> > if they are a bit outdated.
> >
> > Therefore -1.
> You trimmed the vote thread... can we presume you are willing to be
> active in the project?
Sorry, my understanding was that the header tells everything, if there
was an online poll please count this vote as -1 formally as: *not* putting
the stdcxx Apache STL project to Apache Attic.
Of course I would like to contribute if that's possible, I do have a
formal agreement of ARM, at least for the ARM related patches - please
see below.
> > PS: I still have some pending patches to port it to ARM Compiler, if
> > somebody would be happy to review it/commit it I would be happy to
> > follow up - Martin was looking, but we both stuck at some point with
> > having not enough time to do it. Now, as how the things stands I think
> > they should be pushed.
> It's necessary to push these at the bug tracker or the dev@ list. One
> problem is that if you push it to an individual (e.g. Martin) then there
> is no chance the community can help take up the slack when that individual
> gets busy.
I understand that. Some of them were put into Jira:
STDCXX-1051
at least this. I can do some digging and find out if I tracked the other
ones, otherwise I will raise them in Jira.
Wojciech
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 2/5/2012 10:36 AM, Wojciech Meyer wrote:
> Hi all,
>
> -1
>
> This is partially because stdcxx is still considered to be a derivate
> implementation of RogueWave in ARM toolchain, so upgrading at some
> point would have had a smaller impact on our customers than porting
> the toolchain into another library, apart from that I think this means
> that we will have yet smaller choice of C++ libraries avaiable - even
> if they are a bit outdated.
>
> Therefore -1.
You trimmed the vote thread... can we presume you are willing to be
active in the project?
> PS: I still have some pending patches to port it to ARM Compiler, if
> somebody would be happy to review it/commit it I would be happy to
> follow up - Martin was looking, but we both stuck at some point with
> having not enough time to do it. Now, as how the things stands I think
> they should be pushed.
It's necessary to push these at the bug tracker or the dev@ list. One
problem is that if you push it to an individual (e.g. Martin) then there
is no chance the community can help take up the slack when that individual
gets busy.
RE: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Wojciech Meyer <Wo...@arm.com>.
Hi all,
-1
This is partially because stdcxx is still considered to be a derivate
implementation of RogueWave in ARM toolchain, so upgrading at some
point would have had a smaller impact on our customers than porting
the toolchain into another library, apart from that I think this means
that we will have yet smaller choice of C++ libraries avaiable - even
if they are a bit outdated.
Therefore -1.
PS: I still have some pending patches to port it to ARM Compiler, if
somebody would be happy to review it/commit it I would be happy to
follow up - Martin was looking, but we both stuck at some point with
having not enough time to do it. Now, as how the things stands I think
they should be pushed.
Wojciech
________________________________________
From: Farid Zaripov [faridz@apache.org]
Sent: Friday, February 03, 2012 7:34 PM
To: dev@stdcxx.apache.org
Subject: Re: [VOTE] Retirement of stdcxx to the 'Attic'?
On 02.02.2012 19:03, William A. Rowe Jr. wrote:
> Fans and contributors,
>
> it appears that the stdcxx project is entirely dormant. The ASF has
> launched a new 'Attic' project over the past two years, to neatly
> retire dormant works until and unless a community comes along who
> wishes to revive the effort.
>
> As a simple formality your votes please;
>
> [ ] +1 - stdcxx committee should be retired, with code sent to the Attic
>
> [X] -1 - No, stdcxx should not fold, I am still contributing, and
> [would serve|am serving] on its project management committee
>
> The results of this vote will be taken up by the ASF Board of Directors
> at their 15 Feb meeting.
I have not too much time for active developing the stdcxx, but I can
review user patches, test them on a set of Microsoft compilers and
commit into svn.
In the other words, I can provide support of the stdcxx to the users if
any exist :). Also I plan to smoothly move the stdcxx in the C++ 0x
direction.
So my vote is: -1
Farid.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Farid Zaripov <fa...@apache.org>.
On 02.02.2012 19:03, William A. Rowe Jr. wrote:
> Fans and contributors,
>
> it appears that the stdcxx project is entirely dormant. The ASF has
> launched a new 'Attic' project over the past two years, to neatly
> retire dormant works until and unless a community comes along who
> wishes to revive the effort.
>
> As a simple formality your votes please;
>
> [ ] +1 - stdcxx committee should be retired, with code sent to the Attic
>
> [X] -1 - No, stdcxx should not fold, I am still contributing, and
> [would serve|am serving] on its project management committee
>
> The results of this vote will be taken up by the ASF Board of Directors
> at their 15 Feb meeting.
I have not too much time for active developing the stdcxx, but I can
review user patches, test them on a set of Microsoft compilers and
commit into svn.
In the other words, I can provide support of the stdcxx to the users if
any exist :). Also I plan to smoothly move the stdcxx in the C++ 0x
direction.
So my vote is: -1
Farid.
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Stefan Teleman <st...@gmail.com>.
On Thu, Feb 2, 2012 at 12:03, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
Fans and contributors,
it appears that the stdcxx project is entirely dormant. The ASF has
launched a new 'Attic' project over the past two years, to neatly
retire dormant works until and unless a community comes along who
wishes to revive the effort.
As a simple formality your votes please;
[X ] -1 - No, stdcxx should not fold, I am still contributing, and
[would serve|am serving] on its project management committee
The results of this vote will be taken up by the ASF Board of Directors
at their 15 Feb meeting.
I maintain/enahnce stdcxx on Solaris 10 and 11 and Linux at Oracle
(with the Sun Studio compilers). I also test with gcc on the same
platforms (although we do not publish stdcxx for gcc).
stdcxx on Solaris is a long-term commitment on Oracle's part. It will
be available and maintained in Solaris for a long time to come. It
would be very sad for such a nice implementation of C++2003 to be
retired and left to gather dust.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan.teleman@gmail.com
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Michael van der Westhuizen <r1...@gmail.com>.
Sadly, +1.
This is an outstanding piece of software, but it needs active maintenance.
On 02 Feb 2012, at 7:03 PM, William A. Rowe Jr. wrote:
> Fans and contributors,
>
> it appears that the stdcxx project is entirely dormant. The ASF has
> launched a new 'Attic' project over the past two years, to neatly
> retire dormant works until and unless a community comes along who
> wishes to revive the effort.
>
> As a simple formality your votes please;
>
> [ ] +1 - stdcxx committee should be retired, with code sent to the Attic
>
> [ ] -1 - No, stdcxx should not fold, I am still contributing, and
> [would serve|am serving] on its project management committee
>
> The results of this vote will be taken up by the ASF Board of Directors
> at their 15 Feb meeting.
RE: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Scott Zhong <Sc...@roguewave.com>.
I'm voting to keeping this project active.
Scott
-----Original Message-----
From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
Sent: Thursday, February 02, 2012 9:04 AM
To: dev@stdcxx.apache.org
Subject: [VOTE] Retirement of stdcxx to the 'Attic'?
Fans and contributors,
it appears that the stdcxx project is entirely dormant. The ASF has launched a new 'Attic' project over the past two years, to neatly retire dormant works until and unless a community comes along who wishes to revive the effort.
As a simple formality your votes please;
[ ] +1 - stdcxx committee should be retired, with code sent to the Attic
[x] -1 - No, stdcxx should not fold, I am still contributing, and
[would serve|am serving] on its project management committee
The results of this vote will be taken up by the ASF Board of Directors at their 15 Feb meeting.
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
Posted by Andrew Black <An...@roguewave.com>.
+1
While it appears that there is some traffic on the wiki page
(documenting compiler support for various STDCXX 0X features), no effort
is being undertaken to update the library to support these features.
On 02/02/2012 12:03 PM, William A. Rowe Jr. wrote:
> Fans and contributors,
>
> it appears that the stdcxx project is entirely dormant. The ASF has
> launched a new 'Attic' project over the past two years, to neatly
> retire dormant works until and unless a community comes along who
> wishes to revive the effort.
>
> As a simple formality your votes please;
>
> [ ] +1 - stdcxx committee should be retired, with code sent to the Attic
>
> [ ] -1 - No, stdcxx should not fold, I am still contributing, and
> [would serve|am serving] on its project management committee
>
> The results of this vote will be taken up by the ASF Board of Directors
> at their 15 Feb meeting.