On Oct 16, 2010, at 10:21, "Phil Steitz" <phil.ste...@gmail.com> wrote:

> On 10/16/10 12:52 PM, James Carman wrote:
>> On Sat, Oct 16, 2010 at 12:23 PM, Niall Pemberton
>> <niall.pember...@gmail.com>  wrote:
>>> 
>>> Consistency is good, but deciding something based purely on
>>> *consistency* rather than the merits of the situation is mindless.
>>> 
>> 
>> Trying to keep things consistent is being mindful of the user's needs.
>>  The consistency is part of the situation.  When you go to pool
>> version 3, you'll have:
>> 
>> 1.x - commons-pool:common-pool with package org.apache.commons.pool
>> 2.x - org.apache.commons:commons-pool with package org.apache.commons.pool2
>> 3.x - org.apache.commons:commons-pool3 with package org.apache.commons-pool3
> 
> From what Dennis says above, it is not obvious to me that the artifactId 
> change for v 3 will be necessary - i.e., just bumping the version number will 
> allow multiples to be on the classpath at the same time.  Can someone answer 
> this question definitively?  If it will be necessary to move to pool3 later, 
> then I agree with James that we may as well do it now.
> 
>> 
>> Makes lots of sense to the users.
>> 
>> Again, it comes down to "you don't work on this project so stay out of
>> its damn business" and "the release manager is doing the work so they
>> can do whatever the hell they want."  So, why don't we just do what
>> Incubator does and have a mini-PMC for each subproject since you don't
>> want other members of the Commons PMC butting their noses into a
>> project they don't actively participate in?
> 
> I don't think that is what Niall meant and its certainly not how I see 
> things.  A great strength of our community is that we *welcome* input for one 
> another as we make decisions at the component level. We all benefit from 
> that. The tricky bit is to agree on what we standardize across components.  
> We have a long tradition of letting component communities and those who step 
> up to RM releases make a lot of decisions independently.  That does not mean 
> that we shouldn't listen to feedback from the community or provide it when we 
> have something to say.  Nor does it mean that we are not *all* responsible 
> for *all* of our components.  Sometimes we disagree and sometimes it takes a 
> while to get to consensus, but IMO we are *much* better off managing Commons 
> as one community

Yes! To me that's what the commons umbrella should provide. 

Let's reuse the lang3 experience for pool2. And move on IMO. 

>> 
>> At this point, I really don't care what you guys do.  In the grand
>> scheme of things, it has absolutely zero impact on me what you do with
>> this code.  I'm tired of arguing about this stuff all the time.
> 
> I am sorry you feel like that atm.
> 
> Phil
> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to