Thanks Tim,
We have some scheduled tck runs that include a small subset of the tests
which would highlight any major/pervasive issues. Since we haven't
noticed any issues on trunk I doubt we would hit any in branches/2.1
either. For a full run I or somebody else would have to manually kick
it off. I can do that but I might have to wait a few days until I can
get a machine free to try this out.
Regarding the change it general and 2.1.1 ... It looks like we are ok
to leave this wait until 2.1.2 based upon your input and Kevan's
comments. So at this point I do not anticipate including this in 2.1.1
(which I hope I will have available for vote later today ... yes, I know
I said that yesterday too :-( ).
Joe
Tim McConnell wrote:
Hi Joe, the fix has been applied to branches\2.1 and the build works
with it. How a TCK run is scheduled/invoked is unclear to me though.
Please advise if there is something I need to do for that to occur.
Thanks much.
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
Joe
Tim McConnell wrote:
Hi Kevan/Joe, yes GERONIMO-3966 has been classified as a show-stopper
for GEP 2.1, but I "think" we were assuming the problem was in the
GEP and not the server itself. However, it's apparently been a
long-term problem in the server, and is not a windows-only problem,
so I'm not certain that it should be considered a show-stopper for
the GEP. Finally, I really wouldn't feel comfortable propagating it
elsewhere until we have clean TCK run against it since it involves a
change in the geronimo-kernel module. Thanks.
Kevan Miller wrote:
On Apr 21, 2008, at 9:09 AM, Joe Bohn wrote:
Shiva,
The same answer applies here that I just sent to Gianny. I've
included it here as well just so that you don't have to go hunting....
branches/2.1.1 is closed to new changes beyond those which would
prevent us from shipping. I had intended to have images up for
vote a few days ago, but I'm having some difficulty creating those
images. They will hopefully be out for a vote later today.
You should include these changes in branches/2.1 (which has been
updated for 2.1.2-SNAPSHOT).
Sorry to be hard nosed about cutting the release ... but we have to
cut sometime and are always more more items coming in to include.
Hopefully we can get better at releasing smaller releases with more
frequency and 2.1.2 won't be long off.
Joe,
I totally understand the sentiment. However, I believe that
GERONIMO-3966 has been classified as a must fix problem for the
pending release of GEP 2.1. I'd like to hear from Tim/Shiva/etc
whether or not that's true... If true, I think we need to consider
including... If we do pick it up, we should probably grab Gianny's
change...
--kevan
