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.ste...@gmail.com> wrote: > On 10/16/10 3:57 PM, Gary Gregory wrote: >> >> 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. > > +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-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 >> > > > --------------------------------------------------------------------- > 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
