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 &quot;STATUS&quot; 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 &quot;real jobs&quot; 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 &quot;bug fix&quot; 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 &gt;&gt; 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 &lt; 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 &quot;STATUS&quot; 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 &quot;real jobs&quot; 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 &quot;bug fix&quot; 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 &gt;&gt; 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 &lt; 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

Reply via email to