You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@stdcxx.apache.org by "Eric Lemings (JIRA)" <ji...@apache.org> on 2008/01/28 18:51:34 UTC
[jira] Resolved: (STDCXX-691) Global 'size_t' type in source file
'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.
[ https://issues.apache.org/jira/browse/STDCXX-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eric Lemings resolved STDCXX-691.
---------------------------------
Resolution: Fixed
> Global 'size_t' type in source file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.
> ---------------------------------------------------------------------------------------
>
> Key: STDCXX-691
> URL: https://issues.apache.org/jira/browse/STDCXX-691
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Tests
> Affects Versions: 4.2.0
> Reporter: Eric Lemings
> Assignee: Eric Lemings
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> This source file only includes 3 C++ header files, none of which (are supposed to) define the global size_t type, but 'size_t' is referenced as a global type in the for statement. Also, I don't see any using declarations or directives in the file.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
RE: [jira] Resolved: (STDCXX-691) Global 'size_t' type in source file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.
Posted by Eric Lemings <Er...@roguewave.com>.
> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Monday, February 04, 2008 6:56 PM
> 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'.
>
> 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.
Believe me when I say the time tracking feature within Jira has caused
more concern within our particular company, which uses a separate
project management tool, than without.
I agree with all of your conclusions and everyone should be made aware
that use of this feature is purely voluntary and musn't be used for
any actual accounting purposes other than personal management practices.
Some may use it intensively, others (more likely) not at all.
Eric.
Re: [jira] Resolved: (STDCXX-691) Global 'size_t' type in source
file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.
Posted by Martin Sebor <se...@roguewave.com>.
William A. Rowe, Jr. wrote:
> 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.
It's meant to be an experiment to see if we could use it to track
our progress on the huge volume of C++ 0x enhancements (STDCXX-27
and subtasks). The C++ 0x standard is expected to be ratified by
the end of the decade and it would be nice to put out a release
with the new features implemented before then.
Martin
Re: [jira] Resolved: (STDCXX-691) Global 'size_t' type in source
file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
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.
Re: [jira] Resolved: (STDCXX-691) Global 'size_t' type in source
file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.
Posted by Martin Sebor <se...@roguewave.com>.
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).
Martin
Eric Lemings (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/STDCXX-691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Eric Lemings resolved STDCXX-691.
> ---------------------------------
>
> Resolution: Fixed
>
>> Global 'size_t' type in source file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.
>> ---------------------------------------------------------------------------------------
>>
>> Key: STDCXX-691
>> URL: https://issues.apache.org/jira/browse/STDCXX-691
>> Project: C++ Standard Library
>> Issue Type: Bug
>> Components: Tests
>> Affects Versions: 4.2.0
>> Reporter: Eric Lemings
>> Assignee: Eric Lemings
>> Priority: Minor
>> Fix For: 4.2.1
>>
>> Original Estimate: 1h
>> Remaining Estimate: 1h
>>
>> This source file only includes 3 C++ header files, none of which (are supposed to) define the global size_t type, but 'size_t' is referenced as a global type in the for statement. Also, I don't see any using declarations or directives in the file.
>