[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'?
+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.
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
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.tele...@gmail.com
Re: [VOTE] Retirement of stdcxx to the 'Attic'?
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'?
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: [disscuss] Retirement of stdcxx to the 'Attic'?
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: [disscuss] Retirement of stdcxx to the 'Attic'?
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.tele...@gmail.com
