On 12/23/11 9:38 AM, Christian Grobmeier wrote: > 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?
Put energy into 2.0, which is getting close to ready for release. > Should they fork on github instead? > Because we are out of manpower? It comes down to expectations about support. I can seen mine are different. > > 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? All of these things are possible. The problem is who is going to respond to the bug reports and create and port patches. The code - especially the 1.x code - is complicated and I am sure still contains bugs. It is also often implicated in bugs elsewhere in users' infrastructure and tracing line numbers, reviewing issues, etc. requires time. I am not prepared to do that for 3 version concurrently. Hopefully others will step up. Phil > >>>> 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 >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
