Seems a wee bit odd to me to see that "Release Mangers Checklist" on
this page... is that really policy?
--jason
On Mar 27, 2007, at 7:27 AM, [EMAIL PROTECTED] wrote:
Page Edited : GMOxSITE : Project Policies
Project Policies has been edited by Hernan Cunico (Mar 27, 2007).
(View changes)
Content:
Apache Geronimo Policies
Although not easy, here we tray to convey some policies of how the
Apache Geronimo project tackles different processes and every day
decision making situations. This is clearly not an extensive list
but we are working to make it more complete every day.
Non-Geronimo committers contributing to TCK
Apache committers from projects other than Geronimo can request
read only access to TCK following this process:
Requester sends a note to the PMC list requesting access with a
quick summary of their goals.
PMC member acknowledges receipt of the request back to the user.
Same PMC member sends a note to the appropriate keeper of NDAs and
the Geronimo PMC with a subject of:
[TCK] Request for TCK access for Apache Geronimo TCK materials.
Please verify NDA is on file.
and includes relevant information about the committer and their
request.
Waiting period:
Geronimo committers will be granted r/w access upon confirmation of
the NDA being on file.
For other committers the request is available for comment for 72
hours. If there is no -1 on the request and we have received
positive acknowledgment about the NDA then a PMC member sends a
note to the user and PMC with a subject like:
[TCK] Access request for TCK repo from ....... is approved.
The chair or authorized member can update the SVN authorization
file and notify the user of the URL and current relevant
information. Geronimo committers are given r/w access and others
are given read and they can start earning karma.
Release Manager Checklist
Milestone Entry
Clearly declare a milestone release mgr at beginning of the milestone.
Post to the devlist the target delivery schedule of the
milestone. Get consensus from the community early.
Nail the must-have function from the community that is required to
be delivered in this milestone.
Target (or reTarget) all of the Jira defects and new function that
is required for the milestone. Move non-critical items to the next
milestone early.
Milestone Middle
Keep Jiras under control during the milestone. Make sure new
opened ones are targeted for the appropriate milestone, and the
backlog is decreasing.
Make sure the new function Jira are marked appropriately (since
they will be used in the ReadMe file creation).
Look for Jira's that have patches attached to them and get the code
integrated early in the cycle. Don't wait until the last minute.
Make sure that you begin to obtain clean versions for all SNAPSHOTs
in the build. This can sometimes be a lengthy process as dependent
packages are sometimes not available.
Double check that the TCK machines are ready for executing the
TCK. Lay out a plan for the distributed execution of the suite.
Now is the time to ensure that all of the licenses are valid and
replacements/remediation should be done.
Declare a candidate build to the community.
Make sure that you remind the community that all modules should
have the appropriate header file with the appropriate copyright
statement. http://www.apache.org/legal/src-headers.html#headers
<linkext7.gif>
Milestone Exit
Declare a candidate build for the TCK testing to the community and
work any issues that are voiced.
Update the Readme file with the important New Function and Total
defects. Put the delivery date of the milestone in the top of the
readme.
Ensure that tooling is verified with the specific milestone
candidate build (late changes can break tooling, don't ignore this
step).
Double check to make sure that the Graphical Installer works with
the build candidate.
Get some to verify that all of the samples pass without issues.
Complete TCK testing for the build (this normally can take 2-3 weeks).
Near the end of the TCK testing, create a new branch in the build
tree for the milestone. Remind the community that only milestone
defects should be integrated to that branch.
Declare the TCK testing has been completed, and request for a vote
from the community to make this build public. Allow at least 3
days for the vote to complete.
After 3 days, summarize the vote and declare the milestone build as
the public milestone build.
Make approved build available in source and binary form. Declare
this to the community with excitement
<smile.gif>
.
Create Service Branch for the milestone or release (if appropriate).
Post a congratulation note to the dev list thanking the entire
team, and calling out any extraordinary efforts that were done to
make it happen.
Release Branching Process
Procedure
branches/x.y would be the branch for all x.y.z releases
when a release is frozen, we spin off a branch with that exact
name, as in branches/x.y.z, where z starts at zero and increments
by one.
at that time branches/x.y is immediately updated to version x.y.(z
+1)-SNAPSHOT
We cut releases from the frozen branch
When a release passes final tck testing and final vote, the frozen
branch is moved to tags
Rational
We create a branch at freeze time for the following reasons:
it takes at least one week from freeze to ship due to voting, tck
testing and potential repeats of that process (re-cut, re-certify,
re-vote). There is no reason why work on x.y.z+1 needs to be
delayed – only 52 weeks a year.
stronger guarantee no one is updating the branch once frozen
less likely that people and ci systems (continuum) will checkout
and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which
would need to be removed manually and may accidentally be distributed.
it is currently very difficult to roll version numbers forward,
entries here and there are often missed. Far better to have
branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than
a few overlooked x.y.z final numbers that needed to go back to
SNAPSHOT – they never leave SNAPSHOT and need to be reverted back
later if that process happens in the frozen branch.
<warning.gif>
Notice
The process in this document was voted on by the Geronimo
community. Please formally propose all changes to
[EMAIL PROTECTED]
See http://marc.theaimsgroup.com/?l=geronimo-dev&m=115094116905426&w=4
<linkext7.gif>
Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07,
2006) - Bug/feature request
Unsubscribe or edit your notifications preferences
