On 9 June 2011 04:39, Phil Steitz wrote:
> Code in trunk now does not work when distinct pooled instances are
> equal - i.e., if a factory produces instances A and B and
> A.equals(B), this causes problems. I think this situation should
> be allowed - i.e. it is an unacceptable restriction to pu
Code in trunk now does not work when distinct pooled instances are
equal - i.e., if a factory produces instances A and B and
A.equals(B), this causes problems. I think this situation should
be allowed - i.e. it is an unacceptable restriction to put on object
factories that distinct the poolable o
That is GREAT, let's wait for the end of vote, then we will start rockin'! :)
Thanks!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Jun 8, 2011 at 10:54 PM, James Carman
wrote:
> On Wed, Jun 8, 2011 at 4:22 PM, Simone Tripodi
> wrote:
>> I propose a step 0 wh
> -Original Message-
> From: Emmanuel Bourg
> Sent: Wednesday, June 08, 2011 16:25
> To: Commons Developers List
> Subject: Re: [VOTE] Revised dormancy policy - take 3
>
> Le 07/06/2011 22:24, Phil Steitz a écrit :
>
> > 2) To revive a component requires a VOTE. Any ASF committer
> > i
On Wed, Jun 8, 2011 at 4:22 PM, Simone Tripodi wrote:
> I propose a step 0 where we define how generic Graph APIs should look
> like, then define, as you indeed proposed, simple yet powerful
> implementations; users are free to define their own implementations on
> top on our APIs, or wrappers on
Le 07/06/2011 22:24, Phil Steitz a écrit :
2) To revive a component requires a VOTE. Any ASF committer interested in
bringing the zombie back to life can initiate this action. Revival VOTEs
are majority rule.
I'm -1 on this revival rule. A vote implies that the revival could be
rejected, an
Hi Oliver!!!
I propose a step 0 where we define how generic Graph APIs should look
like, then define, as you indeed proposed, simple yet powerful
implementations; users are free to define their own implementations on
top on our APIs, or wrappers on Neo4J
Parallel collections would indeed nice to h
Am 08.06.2011 13:08, schrieb James Carman:
+1, we need a good graph library in the open source world. I would
also like to contribute. It might make me dust off some of my old
textbooks from college! :)
Same situation here. But probably a first step would be to define
efficient but easy to u
GREAT thanks a lot for having taken care about it!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Jun 8, 2011 at 8:01 PM, Christian Grobmeier wrote:
> Hey OGNLers,
>
> the permissions for the incubator website has just been fixed - you
> should now be able to upd
Hey OGNLers,
the permissions for the incubator website has just been fixed - you
should now be able to update the website at your own. At people, you
should see the group "incubator"
Happy uploading ;-)
Cheers,
Christian
-
To
On Wed, Jun 8, 2011 at 12:49 PM, Matt Benson wrote:
> On Wed, Jun 8, 2011 at 10:07 AM, James Carman
> wrote:
>> Perhaps you can re-write this patch yourself in a clean-room environment? :)
>
> I had originally replied to the effect that having already seen and
> applied the patch, I was not reall
On Wed, Jun 8, 2011 at 10:07 AM, James Carman
wrote:
> Perhaps you can re-write this patch yourself in a clean-room environment? :)
I had originally replied to the effect that having already seen and
applied the patch, I was not really free from having seen the patch.
I only just now noticed that
On 6/8/11 6:31 AM, Mark Thomas wrote:
> On 06/06/2011 08:34, Phil Steitz wrote:
>> On 6/5/11 7:32 PM, Phil Steitz wrote:
>>> The AbandonedObjectPool test case that I just commented out in
>>> [dbcp] trunk is failing because GOP getNumActive returns -1. My
>>> first thought was that this is a timin
Hi Simone,
Thanks for the clarifications. I haven't had much need for graph
algorithms other than traversal and shortest path myself, but perhaps I
haven't been thinking hard enough about my data :-).
Based on your clarification, I realize that while there is probably
going to be /some/ overlap,
On 6/8/11 8:05 AM, James Carman wrote:
> On Wed, Jun 8, 2011 at 10:06 AM, Phil Steitz wrote:
>> That would then still require a sandbox promotion VOTE and I see no
>> reason to fuss with moving svn and the site to the sandbox just to
>> revive something. The idea in the proposal is you just go ba
On Wed, Jun 8, 2011 at 11:11 AM, James Carman
wrote:
>>
>
> Why are we going into a long, drawn-out discussion about this? We
> already know how to do a keyed cache (KeyedObjectPool anyone?). If
> you don't want to introduce a dependency, just borrow some code from
> Pool and be done with it.
>
On Wed, Jun 8, 2011 at 11:06 AM, sebb wrote:
>
> Actually, that was not my point - fields written by one thread are not
> necessarily published to other threads without synch.
> Fields may be updated out of order or not at all.
>
> However, I've just realised that there is a real update window:
>
Perhaps you can re-write this patch yourself in a clean-room environment? :)
On Wed, Jun 8, 2011 at 10:59 AM, Matt Benson wrote:
> Hi all,
> I haven't waited long, but it is possible the user who submitted the
> patch for this bug may not respond, and in this case his patch
> consists only of a
On 8 June 2011 15:25, Matt Benson wrote:
> On Tue, Jun 7, 2011 at 8:01 PM, sebb wrote:
>> On 7 June 2011 21:49, wrote:
>>> Author: mbenson
>>> Date: Tue Jun 7 20:49:04 2011
>>> New Revision: 1133155
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1133155&view=rev
>>> Log:
>>> [JXPATH-141] Functi
On Wed, Jun 8, 2011 at 10:06 AM, Phil Steitz wrote:
>
> That would then still require a sandbox promotion VOTE and I see no
> reason to fuss with moving svn and the site to the sandbox just to
> revive something. The idea in the proposal is you just go back to
> hacking on the revived zombie in c
Hi all,
I haven't waited long, but it is possible the user who submitted the
patch for this bug may not respond, and in this case his patch
consists only of a minor tweak to a copy of a method from the same
class, so I think requiring the feather on the JIRA patch is a bit of
overkill in this cas
+1
I kind of know Jelly will come here...
And with this rule, it feels like it might allow me to smoothly restart work on
jelly when time comes, then request a vote for removal of dormancy when I feel
confident.
As answered by Phil to James, I believe that the vote is only considered with
tha
On 6/7/11 3:02 PM, Jason Pyeron wrote:
> -1, needs better handling of details and an outside revival procedure.
Thanks for the feedback. The policy is intended to be a small,
reversible step from current practice, which does not allow
components that have had releases to become dormant. Impleme
On Tue, Jun 7, 2011 at 8:01 PM, sebb wrote:
> On 7 June 2011 21:49, wrote:
>> Author: mbenson
>> Date: Tue Jun 7 20:49:04 2011
>> New Revision: 1133155
>>
>> URL: http://svn.apache.org/viewvc?rev=1133155&view=rev
>> Log:
>> [JXPATH-141] FunctionLibrary Multithreading issue
>
> I don't think thi
On 6/8/11 4:16 AM, James Carman wrote:
> I really don't like the idea of having a vote to revive something
I think we all agree on the "low bar for revival" principle. I
removed the traditional "rule of 3" that we have applied in the past
even for sandbox promotions from the proposal, so all tha
On 06/06/2011 08:34, Phil Steitz wrote:
> On 6/5/11 7:32 PM, Phil Steitz wrote:
>> The AbandonedObjectPool test case that I just commented out in
>> [dbcp] trunk is failing because GOP getNumActive returns -1. My
>> first thought was that this is a timing issue due to lack of
>> synchronization in
Hi James,
my actual proposal is to move the current /trunk to a /DIGESTER_2_X
branch, then moving the sandbox to /trunk.
Yes, I created the sandbox starting from the current /trunk, so all
the svn history will be maintained - feel free to verify it!
Thoughts? Many thanks in advance, have a nice day
I really don't like the idea of having a vote to revive something.
I'd say that if a commons committer has an itch, then let them scratch
it in the sandbox if they want to. Do we really need a special
procedure here? Can't we just say that you have to revive it into the
sandbox and then follow 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
+1, we need a good graph library in the open source world. I would
also like to contribute. It might make me dust off some of my old
textbooks from college! :)
On Tue, Jun 7, 2011 at 3:41 PM, Simone Tripodi wrote:
> Hi all guys,
> I'm in the middle of moving job and in the new company they nee
Why do you want to merge on trunk? You created the branch based on trunk
correct? The history would be there then. I would just swap them out.
Sent from tablet device. Please excuse typos and brevity.
On Jun 3, 2011 6:18 PM, "Simone Tripodi" wrote:
> Hi again guys,
> Clirr report has been upd
31 matches
Mail list logo
