Re: [jira] Resolved: (STDCXX-691) Global 'size_t' type in source file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.

["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'.

[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'.

[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