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
