Return-Path: X-Original-To: apmail-stdcxx-dev-archive@www.apache.org Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A904795EA for ; Fri, 3 Feb 2012 21:51:15 +0000 (UTC) Received: (qmail 18738 invoked by uid 500); 3 Feb 2012 21:51:15 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 18667 invoked by uid 500); 3 Feb 2012 21:51:14 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 18658 invoked by uid 99); 3 Feb 2012 21:51:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Feb 2012 21:51:14 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [64.78.233.62] (HELO moroha.roguewave.com) (64.78.233.62) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Feb 2012 21:51:07 +0000 Received: from vw-fw.roguewave.com (eagle.blue.roguewave.com [10.50.5.40]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id q13LoilH022650 for ; Fri, 3 Feb 2012 21:50:44 GMT Received: from Fountain.Blue.Roguewave.Com (10.55.5.1) by Eagle.Blue.Roguewave.Com (10.50.5.40) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Feb 2012 14:50:08 -0700 Received: from [10.50.4.100] (10.50.4.100) by mymail.roguewave.com (10.55.5.1) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Feb 2012 14:50:08 -0700 Message-ID: <4F2C5645.8000503@roguewave.com> Date: Fri, 3 Feb 2012 16:48:53 -0500 From: Andrew Black User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: Subject: Re: [disscuss] Retirement of stdcxx to the 'Attic'? References: <4F2AC1FE.3040604@rowe-clan.net> <4F2AEF3F.9040500@roguewave.com> <4F2B14E8.6030401@rowe-clan.net> <4F2C3DC1.10002@zaripov.kiev.ua> In-Reply-To: <4F2C3DC1.10002@zaripov.kiev.ua> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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. >