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 Fri, 13 Jul 2007 20:09:25 GMT


Jeff Genender wrote:
> 
> Kevan Miller wrote:
>> We don't know what (if any) delay that we're looking at. To date, our
>> discussions have been that we'll certify both Tomcat/Axis *AND*
>> Jetty/CXF. That's a perfectly valid plan. As you point out, there's a
>> decent chance that the alternate permutations are compliant as well, and
>> we have a certification testing overhead. However, what if some
>> permutations are not compliant? What if one or more technologies are not
>> compliant in any permutation? Do we delay release? Or release with a
>> subset of compliant configurations?
> 
> I think we should give it a shot and if it looks like its going to pass
> or a small fix, then lets do it.  If it shows major errors, then sweep
> it under the rug for the time being and drop the 4 idea.  Lets certainly
> not delay, but lets run 'em.  Best case scenario is they pass and we
> have 4 releases.  Worst is they don't pass and we fall back to the
> original plan.
> 
>> So, our meets-max criteria is certify all permutations of web container
>> and web services technologies. What's meets-min? If we're delaying
>> making a decision on our meets-min criteria, then lets say we'll make
>> this decision at some future date.
> 
> Meets-min == original plan.
> 
>> With regards to what assemblies do we make available? I like your idea
>> of making it easy to switch web services technologies. Continue to
>> deliver Tomcat and Jetty assemblies. The Tomcat assembly defaults to
>> Axis2 for the Web Services implementation. The Jetty assembly defaults
>> to CXF. However, by editing the config.xml, either assembly can be
>> configured to use the alternate Web Services implementation.
>>
> 
> Yep, but I think its a better sell at the end of the day to have all 4
> to met the religious needs.  Again, we can always fall back to what you
> stated above.
> 

Just to be clear ... the "4" assembly solution actually involves 6 
(maybe 7 assemblies) of which we would only certify 4.
- tomcat javaee5 with axis2
- tomcat javaee5 with cxf
- jetty javaee5 with axis2
- jetty javaee5 with cxf
- tomcat minimal
- jetty minimal
- micro-G (Geronimo framework) is still included in the build as an 
assembly as well.  We could choose to skip this assembly for the release 
as our plugin story still isn't complete ... but we delivered this in 1.2

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.

> 
>>> What kind of testing are we talking about.  Certainly not a CTS ;-)
>>> Again, by transitivity, if the big ones run, the little ones should too.
>>>  This should be a relatively small obstacle IMHO.
>> Server starts, you can deploy web apps, the apps work, and the server
>> can be stopped... Something along those lines. Agreed that this is
>> small, but do you agree it's a must-have?
>>
> 
> Yep...was just commenting on the criticality level ;-)

Agreed here as well.  It sounds like a lot of our users are using 
minimal so we want to make sure we don't break them.

> 
>>>> 7. Eclipse Plugin. This won't release concurrently with 2.0. However, we
>>>> should insure that it's on target for release shortly after the server
>>>> release.
>>> +0...since they are on different schedules, I wouldn't hold up one for
>>> the other.
>> They are different schedules, but IMO there should be some level of
>> assurance that the plugin can be made to work. If some part of the
>> server implementation prevents the Eclipse plugin from working with a
>> 2.0 server, is that a stop-release issue?
>>
> 
> IMNSHO..no.  I still see them as 2 separate products...and not everyone
> uses Eclipse (well I do), so I would be against holding up G for the
> Eclipse plugin.
> 
> Jeff
> 

Mime
View raw message