geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: [DISCUSS] 2.0 Release Criteria
Date Sat, 14 Jul 2007 01:06:04 GMT


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.

Mime
View raw message