[pool] 1.5.5 Release

[Phil Steitz <ph...@steitz.com>]

We have resolved a few bugs since 1.5.4 and the remaining issues
marked for 1.5.5 are not that daunting, so I would like to get going
on a release.  I will RM if no one else wants to.  Here is a summary
of all of the issues marked 1.5.5 and how I propose that we handle
them.  As always, comments / patches welcome.

POOL-151:  I would love to conclude that this is a client-side
(i.e., non-[pool]) issue, but the symptoms are strange.  We should
try to get more info from the reporter (possibly recommending to add
explicit synchronization to the factory's makeObject to see if this
resolves it), but not block the release for this issue if we can't
get it resolved by RC-time.  If we have any MQ experts out there who
can verify thread-safety of the factories being used, that would be
helpful.

POOL-158: See comments in the ticket - simple fix.

POOL-159: Looks like a reasonable enhancement request that can be
implemented by looking at the size of the allocation queue.  The
simplest implementation will not be 100% accurate, but probably good
enough to be useful.  I am interested in others' comments on this.

POOL-160: Just need someone to throw the OSGi holy water on what we
are now generating.

POOL-155: My recommendation to essentially (continue to) ignore the
real issue here is a bit smelly and conservative.  I am interested
in others' thoughts on this one.

Beyond the issues above, I intend to continue to chip away at the
documentation deficiencies throughout the code. Many thanks in
advance to any who are willing to help!

I guess one more question to ask is what version of the
commons-parent to inherit from.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [pool] 1.5.5 Release

[Phil Steitz <ph...@gmail.com>]

Niall Pemberton wrote:
> On Sun, Apr 11, 2010 at 7:57 PM, Phil Steitz <ph...@steitz.com> wrote:
>> We have resolved a few bugs since 1.5.4 and the remaining issues
>> marked for 1.5.5 are not that daunting, so I would like to get going
>> on a release.  I will RM if no one else wants to.  Here is a summary
>> of all of the issues marked 1.5.5 and how I propose that we handle
>> them.  As always, comments / patches welcome.
>>
>> POOL-151:  I would love to conclude that this is a client-side
>> (i.e., non-[pool]) issue, but the symptoms are strange.  We should
>> try to get more info from the reporter (possibly recommending to add
>> explicit synchronization to the factory's makeObject to see if this
>> resolves it), but not block the release for this issue if we can't
>> get it resolved by RC-time.  If we have any MQ experts out there who
>> can verify thread-safety of the factories being used, that would be
>> helpful.
>>
>> POOL-158: See comments in the ticket - simple fix.
>>
>> POOL-159: Looks like a reasonable enhancement request that can be
>> implemented by looking at the size of the allocation queue.  The
>> simplest implementation will not be 100% accurate, but probably good
>> enough to be useful.  I am interested in others' comments on this.
>>
>> POOL-160: Just need someone to throw the OSGi holy water on what we
>> are now generating.
> 
> I doubt anyone here could do that. But from experience even asking on
> the Felix list really means nothing - because it hasn't prevented
> issues being later raised. If you use commons-parent-14 then you'll
> get an manifest based on the current advice given by the Felix project
> - I think thats as good as it gets.
> 
>> POOL-155: My recommendation to essentially (continue to) ignore the
>> real issue here is a bit smelly and conservative.  I am interested
>> in others' thoughts on this one.
>>
>> Beyond the issues above, I intend to continue to chip away at the
>> documentation deficiencies throughout the code. Many thanks in
>> advance to any who are willing to help!
>>
>> I guess one more question to ask is what version of the
>> commons-parent to inherit from.
> 
> You need to use version 14 to get the fixes for the OSGi manifest.
> 
Thanks!

Phil
> Niall
>> Phil
> 
> ---------------------------------------------------------------------
> 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

Re: [pool] 1.5.5 Release

[Niall Pemberton <ni...@gmail.com>]

On Sun, Apr 11, 2010 at 7:57 PM, Phil Steitz <ph...@steitz.com> wrote:
> We have resolved a few bugs since 1.5.4 and the remaining issues
> marked for 1.5.5 are not that daunting, so I would like to get going
> on a release.  I will RM if no one else wants to.  Here is a summary
> of all of the issues marked 1.5.5 and how I propose that we handle
> them.  As always, comments / patches welcome.
>
> POOL-151:  I would love to conclude that this is a client-side
> (i.e., non-[pool]) issue, but the symptoms are strange.  We should
> try to get more info from the reporter (possibly recommending to add
> explicit synchronization to the factory's makeObject to see if this
> resolves it), but not block the release for this issue if we can't
> get it resolved by RC-time.  If we have any MQ experts out there who
> can verify thread-safety of the factories being used, that would be
> helpful.
>
> POOL-158: See comments in the ticket - simple fix.
>
> POOL-159: Looks like a reasonable enhancement request that can be
> implemented by looking at the size of the allocation queue.  The
> simplest implementation will not be 100% accurate, but probably good
> enough to be useful.  I am interested in others' comments on this.
>
> POOL-160: Just need someone to throw the OSGi holy water on what we
> are now generating.

I doubt anyone here could do that. But from experience even asking on
the Felix list really means nothing - because it hasn't prevented
issues being later raised. If you use commons-parent-14 then you'll
get an manifest based on the current advice given by the Felix project
- I think thats as good as it gets.

> POOL-155: My recommendation to essentially (continue to) ignore the
> real issue here is a bit smelly and conservative.  I am interested
> in others' thoughts on this one.
>
> Beyond the issues above, I intend to continue to chip away at the
> documentation deficiencies throughout the code. Many thanks in
> advance to any who are willing to help!
>
> I guess one more question to ask is what version of the
> commons-parent to inherit from.

You need to use version 14 to get the fixes for the OSGi manifest.

Niall
> Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org