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

Reply via email to