On Apr 21, 2008, at 4:41 PM, Joe Bohn wrote:
So here is what I understand:
- This is exclusively a G server problem and will not impact the GEP
2.1 release. However, GEP 2.1 could reference Geronimo 2.1.1 if it
is released in time and hence could potentially benefit from this
fix if included in Geronimo 2.1.1
- This is a long time problem that was never identified as a show
stopper for Geronimo (2.1.1 or otherwise). Of course, having a fix
certainly changes the urgency to get it in :-)
- This change is currently integrated into trunk and not branches/
2.1 or branches/2.1.1
- The fix is in a kernel module and as such could potentially affect
various areas in Geronimo (hence the caution of validation via full
TCK runs).
Is this worth further delaying the 2.1.1 release to include this
fix? I was ready to create the release candidate now but this would
delay us several more days before we could even get anything out for
a vote. (BTW, I have already updated the version numbers in branches/
2.1.1 to remove SNAPSHOT in prep for the release).
If we were to pursue this fix we should do the following:
1) Put the change in branches/2.1 first. (it really needs to go
there anyway and it makes much more sense to merge from branches/2.1
to branches/2.1.1 than from trunk to branches/2.1.1) - We should do
this now regardless of the plans for 2.1.1
2) Validate TCK on branches/2.1 (2.1.2-SNAPSHOT)
3) IIF things look good in 2.1.2-SNAPSHOT we would move the fix to
2.1.1
If we're ok with a GEP 2.1 release, then I have no problem proceeding
with what we have... Also, looks like the other problem,
GERONIMO-3970, has a work-around...
--kevan
