Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4EF4A5DE.9050508@gmail.com>
References: 
 <CACZkXPz3OHgGy6ZVJeexOhSx_gaY3dG5R1o6T08zzVCJA6xfpQ@mail.gmail.com>
	<4EF20068.5070200@gmail.com>
	<-209817214533913095@unknownmsgid>
	<4EF2072E.7050403@gmail.com>
	<CAPFNckh4MCD2DYG6cRkJHgz1JDXdTxQRizD43VFoudECpHpC_w@mail.gmail.com>
	<4EF21008.4020207@gmail.com>
	<4EF21F8E.5010204@apache.org>
	<CACZkXPyF82A5-AZaWYLh-sFc0_Ld63hdgcFjANMAyr0YzYo7dA@mail.gmail.com>
	<4EF2261F.1050507@gmail.com>
	<CAPFNckgSwCLd4phhiqcbN7L-g-9Vp7LdCPEUC7fyxyGEqjGF1Q@mail.gmail.com>
	<4EF48233.1010705@apache.org>
	<CAPFNckhcvDgv2_L26j+TJ3NjGA0TqBnHEmciOkFooaXOmAwkcA@mail.gmail.com>
	<4EF4A5DE.9050508@gmail.com>
Date: Sun, 25 Dec 2011 21:41:25 -0500
Message-ID: 
 <CALznzY6ZF7eXUdt3J2duVTmPu3kLFbGwygf1E3NUiMnp=Uxmuw@mail.gmail.com>
Subject: Re: [pool] [POOL-208] Support Java 1.5 Generics in version 1.x.
From: James Carman <jcarman@carmanconsulting.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=20cf307f3a0aeffe5a04b4f5b3ea

--20cf307f3a0aeffe5a04b4f5b3ea
Content-Type: text/plain; charset=ISO-8859-1

You can veto a code modification.
On Dec 23, 2011 11:02 AM, "Phil Steitz" <phil.steitz@gmail.com> wrote:

> On 12/23/11 7:36 AM, Christian Grobmeier wrote:
> > On Fri, Dec 23, 2011 at 2:29 PM, Mark Thomas <markt@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-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
>
>

--20cf307f3a0aeffe5a04b4f5b3ea--