Jeff Genender wrote:
Joe Bohn wrote:
That looks like a lot of assemblies to me. I'd personally prefer to
ship just 4 (or 5) assemblies total with just 2 javaee5 assemblies. We
could still certify all 4 javaee5 permutations even if we don't ship
unique assemblies. However, I think this is a "nice to have" rather
than critical ... time and severity of problems would push us to claim
certification for just 2 (maybe even just 1) configuration.
Anybody have any idea/guess how many users are mostly concerned with the
minimal assemblies? If most users (or a significant number) are on
minimal then we might be spending too much energy trying to decide how
many javaee5 permutations to deliver for very little user benefit. Even
if we deliver just the 2 javaee5 assemblies the users that have a strong
opinion can easily reconfigure the server. My hunch is that most of the
strong opinions are developer opinions rather than opinions based upon
user needs.
Then lets ask the community and get feedback. I personally am speaking
to the CTS releases. The minimals seem as a no-brainer to me. I really
think the quad release is the way to go.
Yes, we should try to get the users' opinion. I was speaking to all of
the assemblies because I was trying to look at things from the user's
perspective when they first go to the Geronimo download page. With the
quad JavaEE5 releases we're giving the user the choice of 7 assemblies
on the download page.
I think running the CTS 2 additional times will not create much of a
delay. If it looks like it will, then we drop the 2 additional. We
also are setting our sites on Tomcat/Axis2 and Jetty/CXF. If we *can*
deliver that, then I think its safe to say that all 4 will pass.
However, its possible that it may end up as Jetty/Tomcat/CXF, because
that one works.
I think we are in agreement on the certification objective:
- We target Tomcat/Axis2 & Jetty/CXF for certification with a target
deadline.
- If we beat our deadline with runway to spare we attempt to certify the
other 2 configurations. If we get it all done then great ... we claim
certification on all 4 configurations. Otherwise we just claim the 2
target configurations as certified. We could do all 4 certifications in
parallel but that would mean less machines available to certify the
target configurations more quickly. It takes close to 3 days for the
tests on a dedicated, fast machine with potential re-runs for the
strange failures that seem to happen in the harness. I was able to
speed this up some last time by splitting the tests on several identical
machines. Given that we don't have an infinite number of machines
running twice the number of tests will most likely double the time to
certify which is why I would prefer to certify the target configurations
and then certify the additional configs with the remaining time.
- If we have problems meeting the deadline for some reason we look for
the most likely configuration to pass and certify that configuration.
I guess to get closer to Kevan's point (and Kevan, correct me if I am
off base here), is...we have a certified stack. Do we want to set a
date and draw a line in the sand for *some* release, whether its, 2 or 4
certified versions, and the mix of configuration is dependent on who
shows up as certified...and then have 2.0.1 be the official release of
all 4? Or do we wait for Axis2 to catch up before an official 2.0 release?
This is where the discussion moves beyond certifying configurations to
the assemblies we create and make available for download.
- If we meet our target (dual) then we ship assemblies of the 2
configurations that passed certification (tomcat/axis2 & jetty/cxf).
- If we fail to meet our target we ship the 1 configuration that passed
as an assembly. This configuration may be neither of the target
configurations (most like it would be Tomcat/CXF that we certified on
previously). IMO we should have at least one assembly that has passed
CTS without any additional configuration necessary so we should
definitely ship this as an assembly. It it wasn't one of the targets
then we should re-evaluate what additional assemblies to ship. It would
seem logical to ship an assembly with the opposite components in the
configuration. (lots of words for an unlikely scenario)
- If we surpass our target and certify on all 4 configurations we could
choose to distribute all 4 assemblies. However, I personally don't
think that is necessary and it may not even be desirable. My initial
reaction is in favor of simplification over giving the user all these
choices when they first go to the Geronimo download page. I think we're
already overly complex with duplicate assemblies based on the web server
impl. Adding the web services impl to the mix and filling out the
matrix just makes it worse. Users that have a strong preference on the
web services impl can easily change the configuration (we could even put
a note on the download page about this). However, since we don't have
data on the user preference one way or the other I think this all comes
down to what we think most users want/need. I think the most users want
simplicity but I'll go along with the group consensus.
Joe, may I ask why you are not up to a quad release if its just running
the tests 2 additional times and causing very little delay?
I ended up answering this above. I hope that helps clarify my opinion.
But it really is just my opinion at this point so I'm open to hearing
other opinions.
