Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (herse.apache.org: domain of kevan.miller@gmail.com
 designates 66.249.82.230 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer;
        b=CTH0HiLXMmB+z4y1NQYbLmUGsYsEjWFcLeY8gQCfZNtfZMfRZVb0gxQJKgSKHcxK3HtF4UOju+Rd61uSHhZxJqhFWDyo8lElKACEphquBL7iEQ6RMYevCqaEmPBbYA+83yTbJdKx2STRYpc5JXK8k9Gd/J3CMJrfmtcdzJ9L9L4=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <C6CD5819-3121-4C45-A49B-0194D19A9205@hogstrom.org>
References: <C6CD5819-3121-4C45-A49B-0194D19A9205@hogstrom.org>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <C29B96FE-8933-41B3-AA59-1A420FF2D336@gmail.com>
Content-Transfer-Encoding: 7bit
From: Kevan Miller <kevan.miller@gmail.com>
Subject: [DISCUSS] 2.0 Release Criteria
Date: Fri, 13 Jul 2007 01:39:20 -0400
To: dev@geronimo.apache.org


On Jun 21, 2007, at 12:34 PM, Matt Hogstrom wrote:

> We've gone through the CTS grind and came out victorious http:// 
> java.sun.com/javaee/overview/compatibility.jsp
>
> OpenEJB has moved to TopLevel and CXF has certified and Axis 2 is  
> working that way too.
>
> All in all its been an excellent six months.
>
> So, what are we going to do for 2.0 and getting it out the door?
>
> Here are my thoughts and we can use this thread to gather everyone  
> else's and come to a consensus.
>
> 2.0 Ship Criteria
> Date:  mid to end of July (a target only...depends on content)
>
> Certified Assemblies
> Tomcat, Axis 2 and OpenJPA
> Jetty, CXF and OpenJPA
>
> Other assemblies would be the minimal assemblies but cert doesn't  
> apply to them.
>
> Work on fit and finish stuff (cleaning up error messages, improving  
> diagnostics, reducing footprint).
>
> Personally, I'd like to see the full G have a footprint of about  
> 40MB (that's a little over 5MB larger than 1.1.1) and Minimal be  
> around 20MB.  Need to do some research on this (volunteers?)
>
> I'm not sure how the WADI clustering presents itself across the two  
> different assemblies (Gianny, comments?)

Beneficial, I think, to conclude/summarize this discussion as we move  
forward to finalizing release plans and dates. Since I'm introducing  
some potentially "new" categorizations, I'm not calling this a  
summary, yet...

In release discussions, like this, I'd like to see us be a little  
clearer with regard to our "must-haves" and "nice-to-haves". In that  
regard, the following is my evaluation of the criteria that we've  
been discussing:

Must-Haves

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?

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

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.

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.

Nice-to-Haves

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