You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axkit-dev@xml.apache.org by AxKit Wiki <axkitwiki> on 2004/05/05 23:06:51 UTC
New Wiki Content at TLPGuidelineProposal
http://axkit.org/wiki/view/AxKit/TLPGuidelineProposal
Wiki content at TLPGuidelineProposal Changed by someone at IP 68.99.184.168 :
@@ -1 +1,394 @@
-foo+<?xml version="1.0" encoding="UTF-8"?>
+<article xmlns="http://localhost/dbk" xmlns:html="http://www.w3.org/1999/xhtml">
+ <title>Apache AxKit Mission Statement and Project Guidelines</title>
+ <section id="mission">
+ <title id="mission.title">AxKit Mission Statement</title>
+ <para>Apache AxKit is project of the Apache Software Foundation, charged with the task of
+ developing and maintaining an Open Source, modular, pipeline-based Web application and
+ publishing environment built upon the Apache HTTP Server, the Perl and C programming
+ languages, and standard and/or popular XML processing technologies. Our goal is to
+ provide an scalable, stable, and flexible framework within which users are free to
+ choose among a series of off-the-shelf components provided by the Apache AxKit Project
+ Community to meet common publishing and application requirements, while ensuring that
+ special needs are easily addressable though the use of user-defined components. </para>
+ <para>We agree, both in principle and practice, with the ideals of the Apache Software
+ Foundation as expressed in the informal list of six principles known colloquially as
+ <emphasis>The Apache Way</emphasis>. Specifically:</para>
+
+ <itemizedlist>
+ <listitem>Collaborative software development</listitem>
+ <listitem>Commercial-friendly standard license</listitem>
+ <listitem>Consistently high quality software</listitem>
+ <listitem>Respectful, honest, technical-based interaction</listitem>
+ <listitem>Faithful implementation of standards</listitem>
+
+ <listitem>Security as a mandatory feature</listitem>
+ </itemizedlist>
+ </section>
+ <section id="guidelines">
+ <title id="guidelines.title">AxKit Project Guidelines</title>
+ <para> This section defines the guidelines for the Apache AxKit 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 AxKit product.</para>
+ <para> 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.</para>
+
+ <section id="guidelines.definitions">
+ <title id="guidelines.definitions.title">Useful Definitions</title>
+ <variablelist>
+ <varlistentry>
+ <term>AxKit Project Management Committee (PMC)</term>
+ <listitem>
+ <para>The group of volunteers who are responsible for managing the AxKit
+ Project. This includes deciding what is distributed as products of the
+ AxKit Project, maintaining the Project's shared resources, speaking on
+ behalf of the Project, resolving license disputes regarding AxKit
+ products, nominating new PMC members or committers, and establishing
+ these guidelines.</para>
+
+ <para>Membership in the AxKit PMC is by invitation only and must be approved
+ by consensus of the active AxKit 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.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>AxKit Committers</term>
+ <listitem>
+ <para>The group of volunteers who are responsible for the technical aspects
+ of the AxKit Project. This group has write access to the appropriate
+ source repositories and these volunteers may cast binding votes on any
+ technical discussion. </para>
+
+ <para>Membership as a Committer is by invitation only and must be approved
+ by consensus of the active AxKit 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). </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>AxKit Developers </term>
+ <listitem>
+ <para>All of the volunteers who are contributing time, code, documentation,
+ or resources to the AxKit Project. A developer that makes sustained,
+ welcome contributions to the project for over six months is usually
+ invited to become a Committer, though the exact timing of such
+ invitations depends on many factors.</para>
+
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>AxKit Project Release Manager (Pumpking)</term>
+ <listitem>
+ <para>An AxKit Committer charged with the co-ordination of the release and maintenance of a single
+ major subversion release of the AxKit Project and each of its micro-versions (1.70 through 1.7x, for example).
+ The Release Manager (RM) is selected based on the consensus approval among active committers of a proposed
+ release plan. This plan then becomes the roadmap for the next development cycle and its author becomes the
+ RM responsible for that subversion.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Release Plan</term>
+ <listitem><para>Drawn from a combination of discussions on the developer's mailing list and open items in
+ the current product's <filename>STATUS</filename> file, a release plan defines the goals and projected
+ time lines for a given subversion release of AxKit, as well as each of its mirco-versions.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Public Mailing List</term>
+
+ <listitem>
+ <para>The AxKit developers' primary mailing list for discussion of issues
+ and changes related to the project (axkit-dev@xml.apache.org).
+ Subscription to the list is open, but only subscribers can post directly
+ to the list. </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Private Mailing List</term>
+ <listitem>
+ <para>The AxKit Group'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 AxKit Group members (Committers).</para>
+
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>CVS</term>
+ <listitem>
+ <para>All of the AxKit products are maintained in shared information
+ repositories using CVS on cvs.apache.org. Only some of the AxKit
+ developers have write access to these repositories; everyone has read
+ access via anonymous CVS. Developers who want write access need to ask
+ for it on the mailing list and, if approved, need to ask the admin of
+ cvs.apache.org for a user account. This, in effect, makes that developer
+ an AxKit Committer.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ </section>
+ <section id="guidelines.STATUS">
+ <title id="guidelines.STATUS.title">The <literal>STATUS</literal> File</title>
+ <para> Each of the AxKit 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 developers 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. </para>
+ <para> 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.</para>
+
+ </section>
+ <section id="guidelines.action-items">
+ <title id="guidelines.action-items.title">
+ <literal>STATUS</literal> Action Items</title>
+ <variablelist>
+ <varlistentry>
+ <term>Long Term Plans</term>
+
+ <listitem>
+ <para>Long term plans are simply announcements that group members are
+ working on particular issues related to the AxKit 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.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Short Term Plans</term>
+ <listitem>
+
+ <para>Short term plans are announcements that a developer is working on a
+ particular set of documentation or code files, with the implication that
+ other developers should avoid them or try to coordinate their changes.
+ This is a good way to proactively avoid conflict and possible
+ duplication of work.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Release Plan</term>
+ <listitem>
+ <para>A release plan is used to keep all the developers 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.</para>
+
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Release Testing</term>
+ <listitem>
+ <para>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 publicly released.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Showstoppers</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>Product Changes</term>
+
+ <listitem>
+ <para>Changes to the AxKit product, including code and documentation, will
+ appear as action items under several categories corresponding to the
+ change status:</para>
+ <variablelist>
+ <varlistentry>
+ <term>concept/plan</term>
+ <listitem>
+ <para>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.</para>
+
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>proposed patch</term>
+ <listitem>
+ <para>A specific set of changes to the current product in the
+ form of input to the patch command (a diff output).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>committed change</term>
+ <listitem>
+ <para>A one-line summary of a change that has been committed to
+ the repository since the last public release.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>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.</para>
+
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </section>
+ <section id="guidelines.voting">
+ <title id="guidelines.voting.title">Voting</title>
+ <para>Any of the AxKit Developers may vote on any issue or action item. However, the
+ only binding votes are those cast by active members of the AxKit Group; 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 developers 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 AxKit Project is a minimum-threshold meritocracy. </para>
+
+ <para> 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 AxKit 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 of 50% of the
+ active AxKit Group membership. </para>
+ <para> Each vote can be made in one of three flavors:</para>
+ <variablelist>
+ <varlistentry>
+ <term>+1</term>
+ <listitem>
+
+ <para>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).</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>±0</term>
+ <listitem>
+ <para>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.</para>
+
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>-1</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+ <para>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. </para>
+ <para> 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.</para>
+ </section>
+ <section id="guidelines.commit">
+ <title id="guidelines.commit.title">When To Commit Changes</title>
+
+ <para>All changes to the currently active repository will be made on commit-then-review
+ (CTR) basis. 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.</para>
+ <para>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 AxKit 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.</para>
+ <para>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.</para>
+ <para>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.</para>
+ <para>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.</para>
+
+ <para>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. </para>
+ </section>
+ <section id="guidelines.patches">
+ <title id="guidelines.patches.title">Patch Format</title>
+ <para>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. Afterwards, the patch summary in the STATUS file should be updated to point
+ to the Message-ID of that message.</para>
+ <para>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.,</para>
+
+ <programlisting><![CDATA[diff -u http_main.c.orig http_main.c >> patchfile.txt]]></programlisting>
+ <para>or</para>
+ <programlisting><![CDATA[cvs diff -u http_main.c >> patchfile.txt]]></programlisting>
+ <para>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.</para>
+ <para> The completed patchfile should produce no errors or prompts when the command,</para>
+ <programlisting><![CDATA[ patch -s < patchfile
+]]></programlisting>
+ <para> is issued in the target repository.</para>
+
+ </section>
+ </section>
+ <section id="addenda">
+ <title id="addenda.title">Addenda and Errata</title>
+ <itemizedlist>
+ <listitem>
+ <para>All URLs and email addresses reflect the current resources available to AxKit
+ as part of the XML PMC and will need to be changed.</para>
+ </listitem>
+
+ </itemizedlist>
+ </section>
+ <!-- <html:script type="text/javascript" src="styles/dbk_css.js"/> -->
+</article>