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
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:/
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 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 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 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 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 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 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
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
>
> ---
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;
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
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!!!
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
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
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
-
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)
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
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
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
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
21 matches
Mail list logo
