Page Edited : GMOxSITE
<http://cwiki.apache.org/confluence/display/GMOxSITE> : Project
Policies
<http://cwiki.apache.org/confluence/display/GMOxSITE/Project+Policies>
Project Policies
<http://cwiki.apache.org/confluence/display/GMOxSITE/Project+Policies>
has been edited by Hernan Cunico
<http://cwiki.apache.org/confluence/display/~hcunico> (Mar 27, 2007).
(View changes)
<http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=49319&originalVersion=10&revisedVersion=11>
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:
o Geronimo committers will be granted r/w access upon
confirmation of the NDA being on file.
o 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]
<mailto:[email protected]>.
See http://marc.theaimsgroup.com/?l=geronimo-dev&m=115094116905426&w=4^
<linkext7.gif>
<http://marc.theaimsgroup.com/?l=geronimo-dev&m=115094116905426&w=4>
Powered by Atlassian Confluence
<http://www.atlassian.com/software/confluence/default.jsp?clicked=footer>
(Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request
<http://jira.atlassian.com/secure/BrowseProject.jspa?id=10470>
Unsubscribe or edit your notifications preferences
<http://cwiki.apache.org/confluence/users/viewnotifications.action>
