You can veto a code modification. On Dec 23, 2011 11:02 AM, "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: > >> > >>> So far i have see the reason: Tomcat 5.5 runs with jdk1.4.2. Is this > >>> actually the reason we don't go forward? Because another project needs > >>> the 1.5 series? > >>> If this is the case, then the EOL of Tomcat 5.5 is the earliest EOL of > Pool 1.5. > >>> > >>> This does mean pool can earliest go forward in September 2012: > >>> http://tomcat.apache.org/tomcat-55-eol.html > >> Pool is already going forward in the 1.6.x branch and in 2.0.x > > You and Phil are raising concerns. I try to discuss these. > > > >>> On 1.6, question is if this series will be so time consuming as > >>> expected. After all, 1.5 dev is at a minimum as understood it. It > >>> should be easy for Gary to move the changes to 1.6 version, if he is > >>> willing to care on that (nasty tongues tell me Git would help in this > >>> case). > >> It is certainly more work but how much more is the critical question. As > >> long as the code bases stay broadly similar it should be easy to patch > >> 1.6.x to fix a bug and svn merge the change to 1.5.x. We do this in > >> Tomcat all the time and merging from trunk (8.0.x) to 7.0.x and 6.0.x is > >> generally fairly simple. Merging to 5.5.x requires more work as the > >> source layout is completely different. > > I have understood Gary that pool 1.6 is the same as 1.5, just with > generics. > > > >> 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? > > 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. > > > >> 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; but as stated above, releases take just 3 +1s and > are not subject to veto, so there is nothing I can do about it. > > 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 > >
