Repository: james-site Updated Branches: refs/heads/asf-site 0e4c47ea0 -> 718c5a85c
Forcing synchronisation Project: http://git-wip-us.apache.org/repos/asf/james-site/repo Commit: http://git-wip-us.apache.org/repos/asf/james-site/commit/718c5a85 Tree: http://git-wip-us.apache.org/repos/asf/james-site/tree/718c5a85 Diff: http://git-wip-us.apache.org/repos/asf/james-site/diff/718c5a85 Branch: refs/heads/asf-site Commit: 718c5a85c0a0e138f7bbfb85e5027339d4c1ccfb Parents: 0e4c47e Author: benwa <btell...@linagora.com> Authored: Wed Aug 9 16:52:26 2017 +0700 Committer: benwa <btell...@linagora.com> Committed: Wed Aug 9 16:52:26 2017 +0700 ---------------------------------------------------------------------- content/guidelines.html | 951 ++++++++++++++++++++++--------------------- 1 file changed, 476 insertions(+), 475 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/james-site/blob/718c5a85/content/guidelines.html ---------------------------------------------------------------------- diff --git a/content/guidelines.html b/content/guidelines.html index 0294fe9..ec9542d 100644 --- a/content/guidelines.html +++ b/content/guidelines.html @@ -1,4 +1,5 @@ <?xml version="1.0" encoding="UTF-8"?> + <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file @@ -22,7 +23,7 @@ <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> - <title>Apache James Project - + <title>Apache James Project - Apache James Project Guidelines</title> <style type="text/css" media="all"> @import url("./css/james.css"); @@ -40,7 +41,7 @@ <meta name="author" content="James Project Web Team" /> <meta name="Date-Revision-yyyymmdd" content="20170809" /> <meta http-equiv="Content-Language" content="en" /> - + <link rel="meta" href="http://james.apache.org//doap_james-project.rdf" title="DOAP" type="application/rdf+xml"/> <!-- Google Analytics --> @@ -192,479 +193,479 @@ </div> <div id="bodyColumn"> <div id="contentBox"> - <!-- Licensed to the Apache Software Foundation (ASF) under one - or more contributor license agreements. See the NOTICE file - distributed with this work for additional information - regarding copyright ownership. The ASF licenses this file - to you under the Apache License, Version 2.0 (the - "License"); you may not use this file except in compliance - with the License. You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, - software distributed under the License is distributed on an - "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY - KIND, either express or implied. See the License for the - specific language governing permissions and limitations - under the License. --> - - - - <div class="section"> -<h2>Apache James Project Guidelines<a name="Apache_James_Project_Guidelines"></a></h2> - -<p> - This document defines the guidelines for the Apache James Project. It - includes definitions of how conflict is resolved by voting, who - is able to vote, and the procedures to follow for proposing and - making changes to the Apache James products. - </p> - -<p> - The objective here is to avoid unnecessary conflict over changes and - continue to produce a quality system in a timely manner. Not all - conflict can be avoided, but at least we can agree on the - procedures for conflict to be resolved. - - </p> - </div> - - -<div class="section"> -<h2>People, Places, and Things<a name="People_Places_and_Things"></a></h2> - -<div class="section"> -<h3>Apache James Project Management Committee<a name="Apache_James_Project_Management_Committee"></a></h3> - -<p> - The group of volunteers who are responsible for managing the Apache - James Project. This includes deciding what is distributed as - products of the Apache James Project, maintaining the - Project's shared resources, speaking on behalf of the Project, - resolving license disputes regarding Apache James products, - nominating new PMC members or committers, and establishing - these guidelines. - </p> - -<p> - Membership in the Apache James PMC is by invitation only and must be approved - by consensus of the active Apache James PMC members. A PMC - member is considered inactive by their own declaration or by - not contributing in any form to the project for over six - months. An inactive member can become active again by - reversing whichever condition made them inactive (i.e., by - reversing their earlier declaration or by once again - contributing toward the project's work). Membership can be - revoked by a unanimous vote of all the active PMC members - other than the member in question. - - </p> - </div> - -<div class="section"> -<h3>Apache James Committers<a name="Apache_James_Committers"></a></h3> - -<p> - The group of volunteers who are responsible for the technical aspects - of the Apache James Project. This group has write access to - the appropriate source repositories and these volunteers may - cast non-binding votes on any technical discussion. - </p> - -<p> - Membership as a Committer is by invitation only and must be approved by - consensus of the active Apache James PMC members. A Committer - is considered inactive by their own declaration or by not - contributing in any form to the project for over six months. - An inactive member can become active again by reversing - whichever condition made them inactive (i.e., by reversing - their earlier declaration or by once again contributing toward - the project's work). Membership can be revoked by a unanimous - vote of all the active PMC members (except the member in - question if they are a PMC member). - - </p> - </div> - -<div class="section"> -<h3>Mailing list<a name="Mailing_list"></a></h3> - -<p> - The Apache committers' primary mailing list for discussion of issues - and changes related to the project - (server-dev@james.apache.org). Subscription to the list is - open, but only subscribers can post directly to the list. - </p> - </div> - -<div class="section"> -<h3>Private list<a name="Private_list"></a></h3> - -<p> - The Apache James Project's private mailing list for discussion of - issues that are inappropriate for public discussion, such as - legal, personal, or security issues prior to a published fix. - Subscription to the list is only open to Apache James PMC - members and Apache Software Foundation Members. - </p> - </div> - -<div class="section"> -<h3>GIT<a name="GIT"></a></h3> - -<p> - All of the Apache James products are maintained in shared information - repositories using GIT on git-wip-us.apache.org. The Apache - committers have write access to these repositories; everyone - has read access via anonymous GIT. - </p> - </div> - </div> - - -<div class="section"> -<h2>Status<a name="Status"></a></h2> - -<p> - Each of the Apache Project's active source code repositories contain a - file called "STATUS" which is used to keep track of the agenda - and plans for work within that repository. The STATUS file - includes information about release plans, a summary of code - changes committed since the last release, a list of proposed - changes that are under discussion, brief notes about items that - individual committers are working on or want discussion about, - and anything else that might be useful to help the group track - progress. The active STATUS files are automatically posted to - the mailing list each week. - </p> - -<p> - Many issues will be encountered by the project, each resulting in zero - or more proposed action items. Issues should be raised on the - mailing list as soon as they are identified. Action items must - be raised on the mailing list and added to the relevant STATUS - file. All action items may be voted on, but not all of them will - require a formal vote. - </p> - </div> - - -<div class="section"> -<h2>Voting<a name="Voting"></a></h2> - -<p> - Any of the Apache James Committers may vote on any issue or action - item. However, the only binding votes are those cast by active - members of the Apache James PMC; if the vote is about a change - to source code or documentation, the primary author of what is - being changed may also cast a binding vote on that issue. All - other votes are non-binding. All committers are encouraged to - participate in decisions, but the decision itself is made by - those who have been long-time contributors to the project. In - other words, the Apache Project is a minimum-threshold - meritocracy. - </p> - -<p> - The act of voting carries certain obligations -- voting members are not - only stating their opinion, they are agreeing to help do the - work of the Apache Project. Since we are all volunteers, members - often become inactive for periods of time in order to take care - of their "real jobs" or devote more time to other projects. It - is therefore unlikely that the entire group membership will vote - on every issue. To account for this, all voting decisions are - based on a minimum quorum. - </p> - -<p> - Each vote can be made in one of three flavors: - </p> - -<p> - <b>+1</b> - <br /> - Yes, agree, or the action should be performed. On some issues, - this vote is only binding if the voter has tested the action on - their own system(s). - </p> - -<p> - <b>+-0</b> - <br /> - Abstain, no opinion, or I am happy to let the other group - members decide this issue. An abstention may have detrimental - effects if too many people abstain. - </p> - -<p> - <b>-1</b> - <br /> - No. On issues where consensus is required, this vote counts as a - veto. All vetos must include an explanation of why the veto is - appropriate. A veto with no explanation is void. No veto can be - overruled. If you disagree with the veto, you should lobby the - person who cast the veto. Voters intending to veto an action - item should make their opinions known to the group immediately, - so that the problem can be remedied as early as possible. - </p> - -<p> - An action item requiring consensus approval must receive at least 3 - binding +1 votes and no vetos. An action item requiring majority - approval must receive at least 3 binding +1 votes and more +1 - votes than -1 votes (i.e., a majority with a minimum quorum of - three positive votes). All other action items are considered to - have lazy approval until someone votes -1, after which point - they are decided by either consensus or a majority vote, - depending upon the type of action item. - </p> - -<p> - Votes are tallied within the STATUS file, adjacent to the action item - under vote. All votes must be either sent to the mailing list or - added directly to the STATUS file entry for that action item. - </p> - -<p> - Votes are to remain open for 72 hours after which the developer who put - forth the vote should tabulate the result and send this to the - mailing list. A developer should be sensitive to holidays that - could dampen participation in the vote. - </p> - </div> - - -<div class="section"> -<h2>Types of Action Items<a name="Types_of_Action_Items"></a></h2> - -<div class="section"> -<h3>Long Term Plans<a name="Long_Term_Plans"></a></h3> - -<p> - Long term plans are simply announcements that group members are working - on particular issues related to the Apache software. These are - not voted on, but group members who do not agree with a - particular plan, or think an alternate plan would be better, - are obligated to inform the group of their feelings. In - general, it is always better to hear about alternate plans - prior to spending time on less adequate solutions. - </p> - </div> - -<div class="section"> -<h3>Short Term Plans<a name="Short_Term_Plans"></a></h3> - -<p> - Short term plans are announcements that a developer is working on a - particular set of documentation or code files, with the - implication that other committers should avoid them or try to - coordinate their changes. This is a good way to proactively - avoid conflict and possible duplication of work. - </p> - </div> - -<div class="section"> -<h3>Release Plan<a name="Release_Plan"></a></h3> - -<p> - A release plan is used to keep all the committers aware of when a - release is desired, who will be the release manager, when the - repository will be frozen in order to create the release, and - assorted other trivia to keep us from tripping over ourselves - during the final moments. Lazy majority decides each issue in - the release plan. - </p> - </div> - -<div class="section"> -<h3>Release Testing<a name="Release_Testing"></a></h3> - -<p> - After a new release is built, colloquially termed a tarball, it must be - tested before being released to the public. Majority approval - is required before the tarball can be publically released. - </p> - </div> - -<div class="section"> -<h3>Showstoppers<a name="Showstoppers"></a></h3> - -<p> - Showstoppers are issues that require a fix be in place before the next public - release. They are listed in the STATUS file in order to focus - special attention on the problem. An issue becomes a - showstopper when it is listed as such in STATUS and remains so - by lazy consensus. - </p> - </div> - -<div class="section"> -<h3>Product Changes<a name="Product_Changes"></a></h3> - -<p> - Changes to the Apache James products, including code and documentation, - will appear as action items under several categories - corresponding to the change status: - </p> - </div> - -<div class="section"> -<h3>Concept/Plan<a name="ConceptPlan"></a></h3> - -<p> - An idea or plan for a change. These are usually only listed in STATUS - when the change is substantial, significantly impacts the API, - or is likely to be controversial. Votes are being requested - early so as to uncover conflicts before too much work is done. - </p> - </div> - -<div class="section"> -<h3>Proposed Patch<a name="Proposed_Patch"></a></h3> - -<p> - A specific set of changes to the current product in the form of - input to the patch command (a diff output). - </p> - </div> - -<div class="section"> -<h3>Committed Change<a name="Committed_Change"></a></h3> - -<p> - A one-line summary of a change that has been committed to the - repository since the last public release. - </p> - -<p> - All product changes to the currently active repository are subject to - lazy consensus. All product changes to a prior-branch (old - version) repository require consensus before the change is - committed. - </p> - </div> - </div> - - -<div class="section"> -<h2>When to Commit a Change<a name="When_to_Commit_a_Change"></a></h2> - -<p> - Ideas must be review-then-commit; patches can be commit-then-review. With - a commit-then-review process, we trust that the developer doing - the commit has a high degree of confidence in the change. - Doubtful changes, new features, and large-scale overhauls need - to be discussed before being committed to a repository. Any - change that affects the semantics of arguments to configurable - directives, significantly adds to the runtime size of the - program, or changes the semantics of an existing API function - must receive consensus approval on the mailing list before being - committed. - </p> - -<p> - Each developer is responsible for notifying the mailing list and adding - an action item to STATUS when they have an idea for a new - feature or major change to propose for the product. The - distributed nature of the Apache project requires an advance - notice of 48 hours in order to properly review a major change -- - consensus approval of either the concept or a specific patch is - required before the change can be committed. Note that a member - might veto the concept (with an adequate explanation), but later - rescind that veto if a specific patch satisfies their - objections. No advance notice is required to commit singular bug - fixes. - </p> - -<p> - Related changes should be committed as a group, or very closely together. - Half-completed projects should not be committed unless doing so - is necessary to pass the baton to another developer who has - agreed to complete the project in short order. All code changes - must be successfully compiled on the developer's platform before - being committed. - </p> - -<p> - The current source code tree should be capable of complete compilation - at all times. However, it is sometimes impossible for a - developer on one platform to avoid breaking some other platform - when a change is committed, particularly when completing the - change requires access to a special development tool on that - other platform. If it is anticipated that a given change will - break some other platform, the committer must indicate that in - the commit log. - </p> - -<p> - The committer is responsible for the quality of any third-party code or - documentation they commit to the repository. All software - committed to the repository must be covered by the Apache - LICENSE or contain a copyright and license that allows - redistribution under the same conditions as the Apache LICENSE. - </p> - -<p> - A committed change must be reversed if it is vetoed by one of the - voting members and the veto conditions cannot be immediately - satisfied by the equivalent of a "bug fix" commit. The veto must - be rescinded before the change can be included in any public - release. - </p> - </div> - - -<div class="section"> -<h2>Patch Format<a name="Patch_Format"></a></h2> - -<p> - When a specific change to the software is proposed for discussion or - voting on the mailing list, it should be presented in the form - of input to the patch command. When sent to the mailing list, - the message should contain a Subject beginning with [PATCH] and - a distinctive one-line summary corresponding to the action item - for that patch. Afterwords, the patch summary in the STATUS file - should be updated to point to the Message-ID of that message. - </p> - -<p> - The patch should be created by using the diff -u command from the - original software file(s) to the modified software file(s). - E.g., - </p> - -<div class="source"> -<pre> - diff -u James.java.orig James.java >> patchfile.txt - </pre></div> - -<p> - All patches necessary to address an action item should be concatenated - within a single patch message. If later modification of the - patch proves necessary, the entire new patch should be posted - and not just the difference between two patches. The STATUS file - entry should then be updated to point to the new patch message. - - </p> - -<p> - The completed patchfile should produce no errors or prompts when the - command, - </p> - -<div class="source"> -<pre> - patch -s < patchfile - </pre></div> - -<p> - is issued in the target repository. - </p> - </div> - - - + <!-- Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. --> + + + + <div class="section"> +<h2>Apache James Project Guidelines<a name="Apache_James_Project_Guidelines"></a></h2> + +<p> + This document defines the guidelines for the Apache James Project. It + includes definitions of how conflict is resolved by voting, who + is able to vote, and the procedures to follow for proposing and + making changes to the Apache James products. + </p> + +<p> + The objective here is to avoid unnecessary conflict over changes and + continue to produce a quality system in a timely manner. Not all + conflict can be avoided, but at least we can agree on the + procedures for conflict to be resolved. + + </p> + </div> + + +<div class="section"> +<h2>People, Places, and Things<a name="People_Places_and_Things"></a></h2> + +<div class="section"> +<h3>Apache James Project Management Committee<a name="Apache_James_Project_Management_Committee"></a></h3> + +<p> + The group of volunteers who are responsible for managing the Apache + James Project. This includes deciding what is distributed as + products of the Apache James Project, maintaining the + Project's shared resources, speaking on behalf of the Project, + resolving license disputes regarding Apache James products, + nominating new PMC members or committers, and establishing + these guidelines. + </p> + +<p> + Membership in the Apache James PMC is by invitation only and must be approved + by consensus of the active Apache James PMC members. A PMC + member is considered inactive by their own declaration or by + not contributing in any form to the project for over six + months. An inactive member can become active again by + reversing whichever condition made them inactive (i.e., by + reversing their earlier declaration or by once again + contributing toward the project's work). Membership can be + revoked by a unanimous vote of all the active PMC members + other than the member in question. + + </p> + </div> + +<div class="section"> +<h3>Apache James Committers<a name="Apache_James_Committers"></a></h3> + +<p> + The group of volunteers who are responsible for the technical aspects + of the Apache James Project. This group has write access to + the appropriate source repositories and these volunteers may + cast non-binding votes on any technical discussion. + </p> + +<p> + Membership as a Committer is by invitation only and must be approved by + consensus of the active Apache James PMC members. A Committer + is considered inactive by their own declaration or by not + contributing in any form to the project for over six months. + An inactive member can become active again by reversing + whichever condition made them inactive (i.e., by reversing + their earlier declaration or by once again contributing toward + the project's work). Membership can be revoked by a unanimous + vote of all the active PMC members (except the member in + question if they are a PMC member). + + </p> + </div> + +<div class="section"> +<h3>Mailing list<a name="Mailing_list"></a></h3> + +<p> + The Apache committers' primary mailing list for discussion of issues + and changes related to the project + (server-dev@james.apache.org). Subscription to the list is + open, but only subscribers can post directly to the list. + </p> + </div> + +<div class="section"> +<h3>Private list<a name="Private_list"></a></h3> + +<p> + The Apache James Project's private mailing list for discussion of + issues that are inappropriate for public discussion, such as + legal, personal, or security issues prior to a published fix. + Subscription to the list is only open to Apache James PMC + members and Apache Software Foundation Members. + </p> + </div> + +<div class="section"> +<h3>GIT<a name="GIT"></a></h3> + +<p> + All of the Apache James products are maintained in shared information + repositories using GIT on git-wip-us.apache.org. The Apache + committers have write access to these repositories; everyone + has read access via anonymous GIT. + </p> + </div> + </div> + + +<div class="section"> +<h2>Status<a name="Status"></a></h2> + +<p> + Each of the Apache Project's active source code repositories contain a + file called "STATUS" which is used to keep track of the agenda + and plans for work within that repository. The STATUS file + includes information about release plans, a summary of code + changes committed since the last release, a list of proposed + changes that are under discussion, brief notes about items that + individual committers are working on or want discussion about, + and anything else that might be useful to help the group track + progress. The active STATUS files are automatically posted to + the mailing list each week. + </p> + +<p> + Many issues will be encountered by the project, each resulting in zero + or more proposed action items. Issues should be raised on the + mailing list as soon as they are identified. Action items must + be raised on the mailing list and added to the relevant STATUS + file. All action items may be voted on, but not all of them will + require a formal vote. + </p> + </div> + + +<div class="section"> +<h2>Voting<a name="Voting"></a></h2> + +<p> + Any of the Apache James Committers may vote on any issue or action + item. However, the only binding votes are those cast by active + members of the Apache James PMC; if the vote is about a change + to source code or documentation, the primary author of what is + being changed may also cast a binding vote on that issue. All + other votes are non-binding. All committers are encouraged to + participate in decisions, but the decision itself is made by + those who have been long-time contributors to the project. In + other words, the Apache Project is a minimum-threshold + meritocracy. + </p> + +<p> + The act of voting carries certain obligations -- voting members are not + only stating their opinion, they are agreeing to help do the + work of the Apache Project. Since we are all volunteers, members + often become inactive for periods of time in order to take care + of their "real jobs" or devote more time to other projects. It + is therefore unlikely that the entire group membership will vote + on every issue. To account for this, all voting decisions are + based on a minimum quorum. + </p> + +<p> + Each vote can be made in one of three flavors: + </p> + +<p> + <b>+1</b> + <br /> + Yes, agree, or the action should be performed. On some issues, + this vote is only binding if the voter has tested the action on + their own system(s). + </p> + +<p> + <b>+-0</b> + <br /> + Abstain, no opinion, or I am happy to let the other group + members decide this issue. An abstention may have detrimental + effects if too many people abstain. + </p> + +<p> + <b>-1</b> + <br /> + No. On issues where consensus is required, this vote counts as a + veto. All vetos must include an explanation of why the veto is + appropriate. A veto with no explanation is void. No veto can be + overruled. If you disagree with the veto, you should lobby the + person who cast the veto. Voters intending to veto an action + item should make their opinions known to the group immediately, + so that the problem can be remedied as early as possible. + </p> + +<p> + An action item requiring consensus approval must receive at least 3 + binding +1 votes and no vetos. An action item requiring majority + approval must receive at least 3 binding +1 votes and more +1 + votes than -1 votes (i.e., a majority with a minimum quorum of + three positive votes). All other action items are considered to + have lazy approval until someone votes -1, after which point + they are decided by either consensus or a majority vote, + depending upon the type of action item. + </p> + +<p> + Votes are tallied within the STATUS file, adjacent to the action item + under vote. All votes must be either sent to the mailing list or + added directly to the STATUS file entry for that action item. + </p> + +<p> + Votes are to remain open for 72 hours after which the developer who put + forth the vote should tabulate the result and send this to the + mailing list. A developer should be sensitive to holidays that + could dampen participation in the vote. + </p> + </div> + + +<div class="section"> +<h2>Types of Action Items<a name="Types_of_Action_Items"></a></h2> + +<div class="section"> +<h3>Long Term Plans<a name="Long_Term_Plans"></a></h3> + +<p> + Long term plans are simply announcements that group members are working + on particular issues related to the Apache software. These are + not voted on, but group members who do not agree with a + particular plan, or think an alternate plan would be better, + are obligated to inform the group of their feelings. In + general, it is always better to hear about alternate plans + prior to spending time on less adequate solutions. + </p> + </div> + +<div class="section"> +<h3>Short Term Plans<a name="Short_Term_Plans"></a></h3> + +<p> + Short term plans are announcements that a developer is working on a + particular set of documentation or code files, with the + implication that other committers should avoid them or try to + coordinate their changes. This is a good way to proactively + avoid conflict and possible duplication of work. + </p> + </div> + +<div class="section"> +<h3>Release Plan<a name="Release_Plan"></a></h3> + +<p> + A release plan is used to keep all the committers aware of when a + release is desired, who will be the release manager, when the + repository will be frozen in order to create the release, and + assorted other trivia to keep us from tripping over ourselves + during the final moments. Lazy majority decides each issue in + the release plan. + </p> + </div> + +<div class="section"> +<h3>Release Testing<a name="Release_Testing"></a></h3> + +<p> + After a new release is built, colloquially termed a tarball, it must be + tested before being released to the public. Majority approval + is required before the tarball can be publically released. + </p> + </div> + +<div class="section"> +<h3>Showstoppers<a name="Showstoppers"></a></h3> + +<p> + Showstoppers are issues that require a fix be in place before the next public + release. They are listed in the STATUS file in order to focus + special attention on the problem. An issue becomes a + showstopper when it is listed as such in STATUS and remains so + by lazy consensus. + </p> + </div> + +<div class="section"> +<h3>Product Changes<a name="Product_Changes"></a></h3> + +<p> + Changes to the Apache James products, including code and documentation, + will appear as action items under several categories + corresponding to the change status: + </p> + </div> + +<div class="section"> +<h3>Concept/Plan<a name="ConceptPlan"></a></h3> + +<p> + An idea or plan for a change. These are usually only listed in STATUS + when the change is substantial, significantly impacts the API, + or is likely to be controversial. Votes are being requested + early so as to uncover conflicts before too much work is done. + </p> + </div> + +<div class="section"> +<h3>Proposed Patch<a name="Proposed_Patch"></a></h3> + +<p> + A specific set of changes to the current product in the form of + input to the patch command (a diff output). + </p> + </div> + +<div class="section"> +<h3>Committed Change<a name="Committed_Change"></a></h3> + +<p> + A one-line summary of a change that has been committed to the + repository since the last public release. + </p> + +<p> + All product changes to the currently active repository are subject to + lazy consensus. All product changes to a prior-branch (old + version) repository require consensus before the change is + committed. + </p> + </div> + </div> + + +<div class="section"> +<h2>When to Commit a Change<a name="When_to_Commit_a_Change"></a></h2> + +<p> + Ideas must be review-then-commit; patches can be commit-then-review. With + a commit-then-review process, we trust that the developer doing + the commit has a high degree of confidence in the change. + Doubtful changes, new features, and large-scale overhauls need + to be discussed before being committed to a repository. Any + change that affects the semantics of arguments to configurable + directives, significantly adds to the runtime size of the + program, or changes the semantics of an existing API function + must receive consensus approval on the mailing list before being + committed. + </p> + +<p> + Each developer is responsible for notifying the mailing list and adding + an action item to STATUS when they have an idea for a new + feature or major change to propose for the product. The + distributed nature of the Apache project requires an advance + notice of 48 hours in order to properly review a major change -- + consensus approval of either the concept or a specific patch is + required before the change can be committed. Note that a member + might veto the concept (with an adequate explanation), but later + rescind that veto if a specific patch satisfies their + objections. No advance notice is required to commit singular bug + fixes. + </p> + +<p> + Related changes should be committed as a group, or very closely together. + Half-completed projects should not be committed unless doing so + is necessary to pass the baton to another developer who has + agreed to complete the project in short order. All code changes + must be successfully compiled on the developer's platform before + being committed. + </p> + +<p> + The current source code tree should be capable of complete compilation + at all times. However, it is sometimes impossible for a + developer on one platform to avoid breaking some other platform + when a change is committed, particularly when completing the + change requires access to a special development tool on that + other platform. If it is anticipated that a given change will + break some other platform, the committer must indicate that in + the commit log. + </p> + +<p> + The committer is responsible for the quality of any third-party code or + documentation they commit to the repository. All software + committed to the repository must be covered by the Apache + LICENSE or contain a copyright and license that allows + redistribution under the same conditions as the Apache LICENSE. + </p> + +<p> + A committed change must be reversed if it is vetoed by one of the + voting members and the veto conditions cannot be immediately + satisfied by the equivalent of a "bug fix" commit. The veto must + be rescinded before the change can be included in any public + release. + </p> + </div> + + +<div class="section"> +<h2>Patch Format<a name="Patch_Format"></a></h2> + +<p> + When a specific change to the software is proposed for discussion or + voting on the mailing list, it should be presented in the form + of input to the patch command. When sent to the mailing list, + the message should contain a Subject beginning with [PATCH] and + a distinctive one-line summary corresponding to the action item + for that patch. Afterwords, the patch summary in the STATUS file + should be updated to point to the Message-ID of that message. + </p> + +<p> + The patch should be created by using the diff -u command from the + original software file(s) to the modified software file(s). + E.g., + </p> + +<div class="source"> +<pre> + diff -u James.java.orig James.java >> patchfile.txt + </pre></div> + +<p> + All patches necessary to address an action item should be concatenated + within a single patch message. If later modification of the + patch proves necessary, the entire new patch should be posted + and not just the difference between two patches. The STATUS file + entry should then be updated to point to the new patch message. + + </p> + +<p> + The completed patchfile should produce no errors or prompts when the + command, + </p> + +<div class="source"> +<pre> + patch -s < patchfile + </pre></div> + +<p> + is issued in the target repository. + </p> + </div> + + + </div> </div> --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org