Le 04/06/2011 04:43, Phil Steitz a écrit :
On 6/3/11 7:27 PM, Henri Yandell wrote:
On Fri, Jun 3, 2011 at 2:09 PM, Simone Tripodi wrote:
I think that is also best practice - resolve when fixed in SVN,
close when fix version is released.
I couldn't agree more!!! +1!
I just close directly. Th
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
I've been doing some experimentation with the JIRA report.
The following configuration IMO produces a reasonable-looking report [1]:
false
Fix Version,Key,Summary,Type,Resolution,Status
Key DESC,Type,Fix Version DESC
Fixed
Resolved,Closed
Bug,New Feature,Task,Improvement,Wish,Test
As mentioned
I like the report. Can you put it in [parent]?
Gary
On Jun 4, 2011, at 11:07, sebb wrote:
> I've been doing some experimentation with the JIRA report.
>
> The following configuration IMO produces a reasonable-looking report [1]:
>
> false
> Fix Version,Key,Summary,Type,Resolution,Status
>
> Ke
On 4 June 2011 16:20, Gary Gregory wrote:
> I like the report. Can you put it in [parent]?
I don't thnk that would work in general.
To make it usable, I had to specify the fix versions, because there
are currently a lot of issues without fix versions (some may be
incorrectly resolved duplicates)
This would match maxTotalPerKey. Note that there is no global
maxIdle. We might want to consider adding that; though to my
knowledge no one has ever asked for it. Same applies to minIdle
(i.e., there is no global minIdle and minIdle probably should be
called minIdlePerKey).
Phil
-
This enum could be replaced by a boolean, now that GROW has been
eliminated.
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
On 6/4/11 8:06 AM, sebb wrote:
> I've been doing some experimentation with the JIRA report.
>
> The following configuration IMO produces a reasonable-looking report [1]:
>
> false
> Fix Version,Key,Summary,Type,Resolution,Status
>
> Key DESC,Type,Fix Version DESC
> Fixed
> Resolved,Closed
>
> Bug
On Fri, Jun 3, 2011 at 7:43 PM, Phil Steitz wrote:
> On 6/3/11 7:27 PM, Henri Yandell wrote:
>> On Fri, Jun 3, 2011 at 2:09 PM, Simone Tripodi
>> wrote:
I think that is also best practice - resolve when fixed in SVN,
close when fix version is released.
>>> I couldn't agree more!!!
Seems good. Something other than NULL probably; and probably should
come up with some bizarre negative number to stay out of the way of
any future JDK items.
On Fri, Jun 3, 2011 at 8:06 PM, sebb wrote:
> On 4 June 2011 03:44, Henri Yandell wrote:
>> Looking more at this one, it looks like the In
It makes a lot of sense and makes clearer fields semantics, +1
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Jun 4, 2011 at 6:01 PM, Phil Steitz wrote:
> This would match maxTotalPerKey. Note that there is no global
> maxIdle. We might want to consider adding that;
if the only available options are now just FAIL/BLOCK, I'm +1
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Sat, Jun 4, 2011 at 6:02 PM, Phil Steitz wrote:
> This enum could be replaced by a boolean, now that GROW has been
> eliminated.
>
> Phil
>
> ---
On 4 June 2011 18:35, Henri Yandell wrote:
> Seems good. Something other than NULL probably; and probably should
> come up with some bizarre negative number to stay out of the way of
> any future JDK items.
Yes, that is a possible issue here. The current JDK only uses positive
integers, so -1 may
On 4 June 2011 18:33, Henri Yandell wrote:
> On Fri, Jun 3, 2011 at 7:43 PM, Phil Steitz wrote:
>> On 6/3/11 7:27 PM, Henri Yandell wrote:
>>> On Fri, Jun 3, 2011 at 2:09 PM, Simone Tripodi
>>> wrote:
> I think that is also best practice - resolve when fixed in SVN,
> close when fix ver
On 04/06/2011 18:41, Simone Tripodi wrote:
> It makes a lot of sense and makes clearer fields semantics, +1
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
+1
Note, there will need to be some refactoring in the Config classes for this.
Mark
> On Sat, Jun 4, 2011 at 6:01 P
On 2011-06-04 19:33, Henri Yandell wrote:
> On Fri, Jun 3, 2011 at 7:43 PM, Phil Steitz wrote:
>> On 6/3/11 7:27 PM, Henri Yandell wrote:
>>> On Fri, Jun 3, 2011 at 2:09 PM, Simone Tripodi
>>> wrote:
> I think that is also best practice - resolve when fixed in SVN,
> close when fix versi
On 2011-06-04 17:06, sebb wrote:
> I've been doing some experimentation with the JIRA report.
>
> The following configuration IMO produces a reasonable-looking report [1]:
>
> false
> Fix Version,Key,Summary,Type,Resolution,Status
>
> Key DESC,Type,Fix Version DESC
> Fixed
> Resolved,Closed
>
>
On 6/4/11 12:05 PM, Mark Thomas wrote:
> On 04/06/2011 18:41, Simone Tripodi wrote:
>> It makes a lot of sense and makes clearer fields semantics, +1
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
> +1
>
> Note, there will need to be some refactoring in the Config classes
On 04/06/2011 22:06, Phil Steitz wrote:
> On 6/4/11 12:05 PM, Mark Thomas wrote:
>> On 04/06/2011 18:41, Simone Tripodi wrote:
>>> It makes a lot of sense and makes clearer fields semantics, +1
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>> +1
>>
>> Note, there will
On 6/4/11 2:08 PM, Mark Thomas wrote:
> On 04/06/2011 22:06, Phil Steitz wrote:
>> On 6/4/11 12:05 PM, Mark Thomas wrote:
>>> On 04/06/2011 18:41, Simone Tripodi wrote:
It makes a lot of sense and makes clearer fields semantics, +1
http://people.apache.org/~simonetripodi/
http:/
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-dbcp2 has an issue affecting its community integration.
This issue
21 matches
Mail list logo
