geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: [DISCUSS] 2.0 Release Criteria
Date Fri, 13 Jul 2007 17:39:08 GMT

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.

>> 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 ;-)

>>> 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?
>  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.


View raw message