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 13:24:13 GMT

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?

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


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


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


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

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

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

> 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