On Fri, Dec 23, 2011 at 5:01 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > On 12/23/11 7:36 AM, Christian Grobmeier wrote: >> On Fri, Dec 23, 2011 at 2:29 PM, Mark Thomas <ma...@apache.org> wrote: >>> On 23/12/2011 11:33, Christian Grobmeier wrote:
>>> Releases would be more work but there are folks that look to be willing >>> to release 1.5.x and 1.6.x >> I guess Gary is willing to serve as a RM for 1.6, I am willing to >> review the relese. > > And Gary is willing to diagnose bugs and apply fixes? And who is > stepping up to review the code in detail? At the moment it seems Gary develops and Simone is reviewing. > The reason I am -1 on this path is that we (mostly I, but most > grateful to Mark for doing most of the work) have done a miserable > job supporting [pool] and [dbcp] over the past several years. I > guess it comes down to how much we feel responsible for supporting > the code we release and I guess my views on this are anachronistic > at this point. > > I have limited time which will soon become even more limited for > contributions here. I can't sign up for more patch porting than we > have already taken on with 1.5.x and 2.0. If others are willing to > step up to actually penetrating the 1.5.x legacy code so they can > fix bugs and respond to user questions, etc.; I will shut up. What is you recommendation for Gary and Simone? Should they fork on github instead? Because we are out of manpower? Other question: can 1.6 be compiled for bytecode 1.4 style? If yes (and it is yes to my knowledge), why can't we go on with 1.6 and provide binries for jdk1.4.2 in addition to jdk5? This way we can bury 1.5 but keep 1.4.2 support. wdyt? >> >>> The other bit I can think of is that the website may need some tweaks to >>> handle multiple versions. I'm not familiar with the Commons web site >>> generation process to judge if that is easy or hard. >> I see this as an additional page in mvn site and a notice on the >> toplevel website. Downloads must be tweaked. >> I might be wrong. >> >>>> If 1.6 is coming and this project does not support it, how can we >>>> handle it? After all we are not working for the Tomcat project, we are >>>> working for ourselves, and Gary needs a generic version. I would not >>>> like to see him going and make up a github fork. People outside of >>>> this project are already saying we are like dinosaurs (collections vs >>>> guava). We should probably discuss how we can do this - probably Gary >>>> could make some kind of "half official" release, a bit of an >>>> "experimental" tagged one. One people do not rely upon, except they >>>> know what they are doing. Probably a 1.5-extended version, like in >>>> Lord of the Rings. >>> All that is required for a release is someone willing to tag and release >>> and three PMC members to vote +1. As long as 1.5.x and 1.6.x remain >>> broadly similar (i.e. 1.6.x = 1.5.x + generics) then the additional work >>> of porting fixes between the two should be minimal. >> This is Garys plan earlier from this thread: >> >> "My plan is to port any fixes from 1.5.x releases to 1.6.0 if any or >> encourage others to do so. I do not plan on touching 1.5.x once 1.6 is >> out. Because of the binary compatibility of 1.6, I would hope that >> folks would patch 1.6 first and then port to 1.5.x if asked by users, >> but that's just me. I see a non-generics pool1 as a dead end. 2.0 is >> great but unreleased and NOT a drop in, hence 1.6." >> >>> We want to avoid "unofficial" releases. >> Pluralis Majestatis? ;-) >> >>> That raises all sorts of red flags at ASF board level. >> I was still speaking of a release with 3x +1. >> >> Anyway it seems your concerns are addressed. > > Not in my opinion; I referred to Marks mails > but as stated above, releases take just 3 +1s and > are not subject to veto, so there is nothing I can do about it. I would prefer a more community approach. That why I try to discuss to my best knowledge here Cheers > Phil >> >> Cheers >> Christian >> >> >>> Mark >>> >>> --------------------------------------------------------------------- >>> 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 > -- http://www.grobmeier.de https://www.timeandbill.de --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
