Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 33145 invoked from network); 5 Feb 2008 01:56:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Feb 2008 01:56:57 -0000 Received: (qmail 50301 invoked by uid 500); 5 Feb 2008 01:56:49 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 50281 invoked by uid 500); 5 Feb 2008 01:56:48 -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 50272 invoked by uid 99); 5 Feb 2008 01:56:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Feb 2008 17:56:48 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [64.202.165.238] (HELO smtpout10.prod.mesa1.secureserver.net) (64.202.165.238) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 05 Feb 2008 01:56:33 +0000 Received: (qmail 1430 invoked from network); 5 Feb 2008 01:56:23 -0000 Received: from unknown (67.162.45.134) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 05 Feb 2008 01:56:23 -0000 Message-ID: <47A7C246.9010704@rowe-clan.net> Date: Mon, 04 Feb 2008 19:56:22 -0600 From: "William A. Rowe, Jr." User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: dev@stdcxx.apache.org Subject: Re: [jira] Resolved: (STDCXX-691) Global 'size_t' type in source file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'. References: <15379715.1201542694807.JavaMail.jira@brutus> <479E173B.4020604@roguewave.com> In-Reply-To: <479E173B.4020604@roguewave.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Martin Sebor wrote: > The issue should be linked as a duplicate of STDCXX-614 and > on closing the Status set to Duplicate. We might also need > to edit the time tracking info so we don't throw off our > reporting (I don't know if it would). Keep in mind, although time tracking is interesting data (even as an open source effort), while you have a community project we need to recognize it's only a rough approximation. Using this as any sort of bookkeeping feature for corporate analysis would be abusing the process. So I agree(d) with turning on the feature, understanding what parts of the code demand the most attention (or possibly also the most audit-from-behind based on the amount of effort expended in certain areas of the code). But I'd disagree if this was expected to be 100% spot-on with the specific time used, and would caution that this feature is essentially opt-in/voluntary and probably variable when it comes to multi-day review of a bug.