stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Lemings" <Eric.Lemi...@roguewave.com>
Subject RE: [jira] Resolved: (STDCXX-691) Global 'size_t' type in source file 'tests/regress/27.stringbuf.xsputn.stdcxx-515.cpp'.
Date Mon, 11 Feb 2008 17:07:04 GMT
 

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

Mime
View raw message