geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: [DISCUSS] 2.0 Release Criteria
Date Fri, 13 Jul 2007 17:22:29 GMT
Hey Jeff,
Thanks for the comments. Followups below...


On Jul 13, 2007, at 9:24 AM, Jeff Genender wrote:

> Kevan Miller wrote:
>> 1. Certification. For M6 we certified a Tomcat/CXF configuration of
>> Geronimo. We'd like to certify 2.0 using Jetty and Axis2, also. What
>> configuration combinations *must* be certified? Is a single certified
>> configuration sufficient? Or do we want to certify with multiple
>> configurations? In an ideal world, I think we'd certify all 4
>> combinations of Web Container and Web Services implementations.   
>> What's
>> our must have set? From discussions to date, it seems to be Tomcat/ 
>> Axis2
>> and Jetty/CXF. However, are we willing to delay a 2.0 release  
>> until both
>> configurations are certified?
> But what kind of a delay are we really looking at?  If Axis certifies
> with Tomcat, and Jetty certifies with CXF, by the rules of  
> transitivity,
> there is a pretty good chance Tomcat/CXF and Jetty/Axis will certify
> just as easily.  If we are not up for releasing 4 (which IMHO is not a
> big deal), then we really need to monitor the lists for what
> configurations users want.  Religious wars abound on web service
> containers just as fiercely as the servlet containers do.  Why not
> consider a quad release for 2.0 and see if it was painful/painless to
> run 4 certification runs?  Based on the pain threshold, let the  
> download
> count decide at the end of the day for what are default builds?

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?

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.

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.

> As a side note (because I know it will be brought up), I do not  
> think we
> are going down a slippery slope regarding certifying *any*
> configuration, and I think we are hitting just the major religious  
> tones.


>> 2. Fit and Finish. The "must-have" list would include Release Notes,
>> appropriately licensed source files, and up-to-date license and  
>> notice
>> files. Other "Fit-and-Finish" items have been proposed. All are good
>> ideas. However, in my book, they fall into the "nice-to-have"  
>> category
>> and are included below. I'd like to be careful with this category.
>> Otherwise, we end up with an always shifting target
> +1
>> 3. Additional Features. With Gianni's latest WADI updates, I believe
>> that people are happy with the current set of functionality. Now  
>> would
>> be a really good time to voice any disagreements. ;-) This also  
>> implies
>> that we should be careful about starting new function development on
>> trunk. Also begs the question of when we move "2.0" off of trunk and
>> into a branch... I know some people are holding off new function  
>> until
>> 2.0 has been branched.
> +1
>> 4. Bug Fixes. Recent testing with DayTrader has identified several
>> deployment and memory-related problems which seem to fall into the
>> must-fix category. David J had a problem with manifest classpaths  
>> that
>> he was fixing. If we have other must-fix bugs, we should call them  
>> out
>> now. Naturally new must-fix problems may be raised prior to release.
>> However, we should avoid last minute surprises.
> +1
>> 5. Dependencies. A number of our dependencies are SNAPSHOT  
>> dependencies.
>> Many of these projects have or are in the process of being released.
>> Very difficult/impossible to get *all* projects lined up on a release
>> train. Also, likely that we'll have to Geronimo specific builds of  
>> some
>> projects (e.g. Tomcat).
> Those that are SNAPSHOT will need a good prodding and we should  
> probably
> begin that process now.

That process has already begun.

>> 6. Little-G. I don't know of much testing that's occurred of our
>> Little-G configurations. We need to perform a basic validation of  
>> these
>> assemblies.
> 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?

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

>> Nice-to-Haves
> +1 on the rest of these.
>> 1. Fit and Finish. Reducing download and runtime size have been  
>> proposed
>> as potential improvements. There was a fair amount of discussion
>> regarding download size. However, I don't see much active work
>> occurring. Improving performance is always nice... ;-) There was also
>> discussion of removing duplicate artifacts from our assemblies (i.e.
>> being smarter about what artifacts are being included by the  
>> maven2 war
>> plugin and cleaning up some of our configurations) -- it would be  
>> great
>> to see some of these issues fixed. However, IMO, it need not hold  
>> up a
>> release.
>> 2. Usability. There are a number of usability improvements (e.g.
>> improved messages and diagnostics) which have been proposed. There  
>> has
>> been progress in this area already. My sense is we're ready to go  
>> with
>> what we've got. We can make incremental improvements, of course.
>> However, I don't see a complete overhaul prior to 2.0 in the works...
>> 3. Additional Features. As mentioned previously, we want to be  
>> careful
>> about introducing new instabilities (I mean features ;-).
>> 4. Bug Fixes. We can be a bit more aggressive, here. However, I  
>> think we
>> need to still weigh potential instabilities against the anticipated
>> benefits.
>> --kevan

View raw message