commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] time to move groupId?
Date Sun, 17 Oct 2010 12:07:07 GMT
done on trunk, svn history has been preserved.
Have a nice Sunday,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Sun, Oct 17, 2010 at 3:11 AM, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 10/16/10 3:57 PM, Gary Gregory wrote:
>>
>> On Oct 16, 2010, at 10:21, "Phil Steitz"<phil.steitz@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.pemberton@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.
>
> +1
>
> Sorry I did not understand what was going on at first. I am +1 for doing all
> three changes:
>
> commons-pool -> org.apache.commons
> commons-pool -> commons-pool2
> org.apache.commons.pool -> org.apache.commons.pool2
>
> Thanks!
>
> Phil
>>
>>>>
>>>> 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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message