Beehive Developers,

Now that we have gotten our second Beta approved, I thought it an
appropriate time to present what I feel are the release criteria for
Beehive 1.0.  

I would expect the process around these to go as follows.  

1) Present criteria (this email) and post the same on the wiki.
2) Give roughly 48 hrs for disagreement (removals or additions).
3) Then solicit owners of the various objectives.

So here is the proposed list of release criteria for v1 Beehive. In the
remainder of this document, the Subversion revision number that
(eventually) reflects Beehive 1.0 will be simply referred to as the
release candidate.  

The release criteria generally fall into one of the following areas:
Source Tree, Distribution Bits, Release Planning, and Documentation.  

SOURCE TREE
The following indicate activities that must occur in the Beehive
Subversion Source Tree before we are ready to ship Beehive 1.0.

#1.0    
Objective: All DRTs/Checkin tests pass at 100% when executed against the
release candidate revision number in the source tree.
Background: All DRTs must pass at 100% for NetUI, JWS and Controls.
Gating: Yes

#1.1
Objective: All BVT/detailed tests pass at 100% when executed against the
release candidate revision number in the source tree.   
Background: Any BVTs/detailed tests not passing should have JIRA issue
filed and be commented out for the release candidate.  If at a later
date a fix is to be added to 1.0 (something like 1.0.1) the test can be
re-enabled in the 1.0 branch or in the next major release (1.1 or 2.0)
Gating: Yes

#1.2
Objective: Any tests commented out due to failures should have JIRA
issues filed (defects or enhancements) to be fixed in subsequent
releases. Comments within test configuration files should indicate the
JIRA issue tracking the problem.
Background: N/A
Gating: Yes

#1.3
Objective: The website content must be generated in support of the
release candidate.
Background: N/A
Gating: Yes

#1.4
Objective: The javadoc target for the release candidate must be able to
pass successfully.
Background: We must be able to successfully build the javadoc.
Gating: Yes

DISTRIBUTION BITS
The following indicate activities that must occur in support of the
Beehive Distribution.

#2.0
Objective: The Beehive Distribution must be able to be created from the
release candidate.
Background: We must be able to build the distribution from the release
candidate.
Gating: Yes

#2.1
Objective: The Beehive Test Distribution must be able to be created from
the release candidate.
Background: We must be able to build the test distribution from the
release candidate. This is really needed to verify bits in the
distribution.
Gating: Yes

#2.2
Objective: All tests (DRTs/checkin/BVTs/detailed) in support of Beehive
must be able to be executed from the test distribution against the
distribution derived from the release candidate.
Background: Thus test code must fully be enabled to run in this manner.
Gating: Yes

#2.3
Objective: All DRTs/Checkin tests must pass at 100% when executed from
the test distribution against the distribution for the release candidate
for Windows 2003 Server.
Background: We need the same pass rate to verify it is a good
distribution.
Gating: Yes

#2.4
Objective: All DRTs/Checkin tests must pass at 100% when executed from
the test distribution against the distribution for the release candidate
for Redhat Linux AS 3.0.
Background: We need the same pass rate to verify it is a good
distribution.
Gating: Yes

#2.5
Objective: All BVT/Detailed tests must pass at 100% when executed from
the test distribution against the distribution for the release candidate
for Window 2003 Server.
Background: We need the same pass rate to verify it is a good
distribution.
Gating: Yes

#2.6
Objective: All BVT/Detailed tests must pass at 100% when executed from
the test distribution against the distribution for the release candidate
for Redhat Linux AS 3.0.
Background: We need the same pass rate to verify it is a good
distribution.
Gating: Yes

#2.7
Objective: The distribution created from the release candidate must be
published for download and signed.
Background: N/A
Gating: Yes

#2.8
Objective: The JSR 181 Technology Compatibility Kit (TCK) must pass
against the distribution derived from the release candidate. 
Background: N/A
Gating: Yes

RELEASE PLANNING
The following indicate activities that must occur in support of the
Beehive Distribution for Release Planning.

#3.0
Objective: The release candidate needs to be proposed for vote within
Apache.  This needs to be a minimum of three days prior to release and
needs to include all documentation, tests.
Background: We should not go to vote until all docs are ready including
samples, user guides, java doc, etc.
Gating: Yes

#3.1
Objective: The vote submitted for the release candidate must pass.
Background: N/A
Gating: Yes

#3.2
Objective: A list of known issues must be produced and published in
support of the release candidate.  This should capture all known defects
(from JIRA) the user may encounter.  This need not include enhancements
and documentation bugs.
Background: Could be published as part of the dist itself or perhaps on
the Beehive website.  If part of the dist, must be made before the vote.
Gating: No

#3.3
Objective: For the release candidate, no open bugs will exist.  All
items will be fixed or assigned to the new release.
Background: Currently all things for the future are assigned to Fix For
version equal to "TBD".
Gating: No

DOCUMENTATION
#4.0
Objective: All samples must be completed for the release candidate. The
samples list includes: 
   1) Petstore 
   2) External config feature samples 
   3) DB control 
   4) Service control 
   5) JSF sample
Background: List may grow.
Gating: Yes

#4.1
Objective: All samples must be part of the distribution for the release
candidate.  
Background: These need to be proofed and executed.
Gating: Yes

#4.2
Objective: All Java Doc for "Public Use" APIs must be authored as part
of the release candidate.
Background: This is mainly a driver to indicate if there is any API that
we intend users to implement/understand, Javadoc must be provided.
These need to be authored/proofed by developers.
Gating: Yes

#4.3
Objective: All tutorials on the website must be able to be successfully
executed against the distribution created from the release candidate.
Background: N/A
Gating: Yes 

#4.4
Objective: The Beehive website must be updated to support the release
candidate, including samples, download information, etc.
Background:
Gating: Yes

Thanks
Steve

Reply via email to